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ABSTRACT 


The  United  States  Navy  is  currently  implementing  a  plan 
to  consolidate  the  wholesale  supply  functions  of  the  Naval 
Air  Station  at  Alameda  and  the  Naval  Supply  Center  at  Oakland. 
Improving  supply  support  of  the  Naval  Air  Rework  Facility 
Alameda  in  general  and  stock  availability  in  particular  is  a 
vital  part  of  the  plan.  Demand  forecasting  by  workload  driven 
material  requirements  planning  (MRP)  is  being  considered  as 
a  means  to  improve  stock  availability.  This  thesis  begins 
with  an  overview  of  the  MRP  technique  and  the  current  supply 
support  of  NARF  Alameda.  It  proceeds  with  the  description 
and  evaluation  of  a  temporary  MRP  system  that  is  currently 
implemented  and  uses  it  as  a  background  for  development  of 
an  MRP  system  that  is  designed  to  operate  in  a  maintenance 
oriented  environment  in  general  and  at  NARF  Alameda  in 
particular.  Finally,  suggestions  are  made  for  transition 
from  the  temporary  to  the  proposed  system. 


TABLE  OF  CONTENTS 


INTRODUCTION . 11 

MATERIAL  REQUIREMENTS  PLANNING  (MRP) . .  13 

A.  BACKGROUND:  PRODUCTION  AND  INVENTORY 

CONTROL . - .  13 

B.  MATERIAL  REQUIREMENTS  PLANNING  CONCEPT .  16 

C.  ASSUMPTIONS  AND  PREREQUISITES .  20 

D.  MRP  SYSTEM  OUTPUT .  25 

E.  MRP  AND  CONVENTIONAL  INVENTORY  CONTROL .  28 

F.  IMPLEMENTING  AN  MRP  SYSTEM .  30 

G.  CONCLUSIONS . - .  36 

SUPPLY  SUPPORT  OF  NARF  ALAMEDA .  38 

A.  CONCEPT  AND  OPERATION .  38 

1.  Pre-Consolidation  Support . 40 

2.  Post-Consolidation  Support .  42 

B.  AUTOMATED  DATA  PROCESSING  OVERVIEW .  46 

1.  Data  Processing  Equipment  and 

Applications  at  NSC  Oakland . • .  46 

2.  The  Inventory  Management  Subsystem . -  49 

3.  Data  Files .  50 

4.  UADPS  and  MRP .  52 

C.  EVALUATION  AND  CONCLUSIONS .  53 

THE  TEMPORARY  MRP  APPLICATION .  55 

A.  SYSTEM  OVERVIEW .  56 

B.  MRP  DATA-BASE .  58 

C.  SOFTWARE .  66 


5 


D.  INPUT,  OUTPUTS  AND  PROCESSING . 

E.  EVALUATION  OF  THE  TEMPORARY  MRP  SYSTEM 


70 


V.  THE  PROPOSED  MRP  SYSTEM . 76 

A.  PRM-MRP:  PROBABILISTIC  REPLACEMENT 

MODEL  FOR  MRP . 78 

1.  The  Demand  Distribution . - . - . 78 

2.  The  Basic  Model . 80 

3.  Extensions  of  the  Basic  Model-- . 85 

B.  SUPPORTING  INFORMATION-- . 89 

1.  Outputs,  Inputs  and  Data-Base . . -89 

2.  Functions . - . 90 

3.  Algorithms . 90 

4.  Environment . -91 

5.  Information  Network . 91 

C.  MATERIAL  REQUIREMENTS  ALGORITHM . 91 

D.  THE  PRODUCTION  CONTROL  SUBSYSTEM . 98 

E.  DATA  BASE  DESIGN . Ill 

1.  The  BOM  File . - . Ill 

2.  FIC  to  IIC  Translation  Table . 114 

3.  Other  Files . . - . - . 116 

F.  SOFTWARE  DESIGN . 117 

1.  File  Maintenance . 117 

2.  Queries . 131 

3.  Requirements  Generation . 131 

4.  General  Purpose  Subroutines . 134 

G.  SYSTEM  CONFIGURATION . 136 

1.  On-Line  Storage . 136 

2.  Off-Line  Storage . 138 


6 


3.  Main  Memory . 138 

4.  Processing  Time . - . 138 

5.  Conclusions . - . 141 

H.  COST-BENEFITS  ANALYSIS--- . 142 

I.  IMPLEMENTATION  PLAN . 145 

VI.  CONCLUSIONS  AND  RECOMMENDATIONS . . 14  8 

APPENDIX  A:  List  of  Selected  UADPS-SP  Files . . . 153 

APPENDIX  B:  Supporting  Data . - . 154 

APPENDIX  C:  Software  Development . - . -156 

APPENDIX  D:  Updating  Replacement  Factors . 162 

APPENDIX  E:  Further  Discussion  of  the  PRM-MRP  Model - 166 

LIST  OF  REFERENCES . 171 

INITIAL  DISTRIBUTION  LIST . 173 


7 

a 


LIST  OF  ABBREVIATIONS 


ADP  Automated  Data  Processing 

ASKARS  Automated  Storage,  Kitting  and  Retrieval  System 

ASO  Aviation  Supply  Office 

BOM  Bill  of  Materials 

CWF  Committed  Workload  File 

DHF  Demand  History  File 

DLA  Defense  Logistic  Agency 

DMF  Demand  Master  File 

DODMDS  Department  of  Defense  Material  Distribution  Study 

DPD  Data  Processing  Department 

FIC  Family  Identification  Code 

FMSO  Fleet  Material  Support  Office 

IIC  Item  Identification  Code 

IM  Item  Manager 

MRP  Material  Requirements  Planning 

MSIR  Master  Stock  Item  Record  (file) 

NARDAC  Navy  Regional  Data  Automation  Center 

NARF  Naval  Air  Rework  Facility 

NAS  Naval  Air  Station 

NASA  Naval  Air  Station  Alameda 

NAVSUP  Naval  Supply  System  Command 

NIF  Navy  Industrial  Fund 

NIIN  Navy  Item  Identification  Number 

NIMMS  Naval  Air  Industrial  Material  Management  System 


8 


NISTARS  Naval  Integrated  Storage  and  Retrieval  System 

NSC  Naval  Supply  Center 

NSCO  Naval  Supply  Center  Oakland 

NSF  Navy  Stock  Fund 

OSI  Operadonal  Support  Inventory 

PCS  Production  Control  Subsystem 

PEB  Pre-Expended  Bin 

POE  Point  of  Entry 

QFT  Quarterly  Family  Tape 

RDF  Report  Data  File 

RSF  Requisition  Status  File 

RSS  Ready  Supply  Store 

SER  Shore  Establishment  Realignment 

SLT  Sorted  Labor  Transactions  (file) 

SPCC  Ships  Parts  Control  Center 

SSD  Specialized  Supply  Depot 

UADPS-SP  Uniform  Automated  Data  Processing  System-Stock  Poin 
UICP  Uniform  Inventory  Control  Program 

VOSL  Variable  Operating  and  Safety  Level 


9 


ACKNOWLEDGEMENTS 


I  wish  to  express  my  gratitude  to  Professor  A.  W.  McMasters 
and  Professor  N.  F.  Schneidewind,  my  thesis  advisors,  for  their 
support  and  assistance.  My  special  thanks  also  to  LCDR 
Benefiel  at  NARF  Alameda  who  gave  of  his  time  and  energies  and 
supplied  materials  and  information  to  help  me  in  this  endeavor 


10 


I.  INTRODUCTION 


The  DOD  Material  Distribution  Study  (DODMDS)  [7:8] 
attempted  to  determine  the  number  and  locations  of  wholesale 
activities  necessary  to  provide  efficient  and  cost  effective 
distribution  of  materials.  As  a  consequence  of  the  recommen¬ 
dations  of  that  study,  the  Naval  Supply  System  Command  (NAVSUP) 
initiated  the  Shore  Establishment  Realignment  (SER)  which  will 
consolidate  the  wholesale  supply  functions  of  the  Naval  Air 
Stations  (NAS)  at  Alameda,  North  Island  and  Norfolk  with  the 
Naval  Supply  Centers  at  Oakland,  San  Diego  and  Norfolk, 
respectively. 

NAVSUP  has  specified  that  the  consolidation  is  not  to 
degrade  the  supply  support  provided  currently  by  the  NAS  supply 
departments.  However,  it  will  be  beneficial  to  the  system-- 
and  especially  to  the  Naval  Air  Rework  Facility  (NARF)  as  one 
of  the  customers- -to  achieve  not  only  reduced  costs,  but  also 
improved  service. 

SER  and  the  NARF ' s  desire  to  maximize  improvements  has 
necessitated  a  basic  reappraisal  of  the  NARF/Supply  System 
interfaces.  The  result  [10]  was  identification  of  the  fol¬ 
lowing  problem  areas  and  possible  improvements: 

1.  Response  time, can  be  improved  by:- 

a.  Mechanized  requirements  submission 

b.  Automated  inventory  control  and  materials  handling 

2.  Stock  availabil ity,  can  be  improved  by : - 

a.  Demand  forecasting  by  workload  driven  material 
requirements  planning  (MRP) . 


This  study  was  done  as  part  of  the  NARF's  effort  to 
clearly  identify  the  problem  areas  in  its  supply  support  and 
find  the  best  solutions  to  those  problems.  This  study  attacks 
specifically  the  stock  availability  problem  and  justifies  why 
MRP  is  the  solution. 

The  implementation  of  MRP  is  integrated  into  the  consoli¬ 
dation  process  and  the  implementation  of  response  time  improve¬ 
ments  in  the  system.  As  a  result,  the  implementation  of  MRP 
consists  of  two  phases :- 

I.  Implementation  of  a  temporary  system  that  will  run  on 
existing  equipment  and  will  be  used  to  gain  experience 
with  the  system  and  build  up  the  necessary  data  files. 

This  phase  will  include  the  design  of  the  target  system. 

II.  Implementation  of  the  final  system  on  the  new  computer¬ 
ized  material  handling  equipment- -namely,  NISTARS/ASKARS 
(Naval  Integrated  Storage  and  Retrieval  System/Automated 
Storage,  Kitting  and  Retrieval  System). 

This  thesis  describes  briefly  the  development  and  imple¬ 
mentation  of  Phase  I  and  uses  it  as  a  background  for  a  proposed 
design  and  integration  of  the  final  MRP  system  with  the  standard 
ASKARS  software  and  database. 
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II.  MATERIAL  REQUIREMENTS  PLANNING 


A.  BACKGROUND:  PRODUCTION  AND  INVENTORY  CONTROL 

Production  and  inventory  control  emerged  as  independent 
management  tools.  Production  control,  in  the  very  beginning, 
was  one  of  the  functions  performed  by  the  line  foreman.  He 
ordered  materials,  hired  people  and  decided  what,  how  and 
how  much  to  produce.  As  his  workload  increased,  the  first 
task  to  be  assigned  to  someone  else  was  the  ordering  of 
materials.  Along  with  that,  there  were  also  a  few  attempts 
to  develop  a  scientific  approach  to  production  control. 
However,  general  applications  did  not  develop  prior  to  World 
War  II.  After  the  war,  industry  needed  maximum  production 
since  there  was  an  almost  insatiable  demand  for  products. 

The  main  problem  was  how  to  make  more  and  more  products,  not 
necessarily  how  to  make  them  more  efficiently  [1:XIII], 

This  environment  gave  a  big  push  to  production  planning 
and  many  techniques  evolved,  mainly  oriented  towards  pro¬ 
duction  with  little  consideration  of  the  related  inventory 
problems.  Among  those  techniques  were  Gantt  charts  [1:13.33], 
Line  of  Balance  [1:13.23],  Network  Methods  [1:13.33]  and 
Linear  Programming  [1:13.45].  It  seemed  apparent  that  these 
techniques  had  great  potential  to  improve  both  production  and 
inventory  control  which  frequently  deal  with  uncertainty, 
especially  because  of  the  little  attention  these  functions 
had  received  from  management. 


13 


Inventory  control,  on  the  other  hand,  developed  in  a 
more  "natural"  way.  The  concept  of  economic  lot  sizing  and 
reorder  points  was  first  presented  by  Ford  Harris  in  1915 
and  later  developed  by  R.  H.  Wilson  in  1934  [14:3].  But  it 
was  only  after  World  War  II  that  that  theory  had  seen  real 
application,  after  stochastic  inventory  models  were  developed 
and  could  use  this  theory  in  a  more  realistic  way. 

The  biggest  problem  in  applying  the  scientific  techniques 
in  industry  has  been  the  fact  that  companies  were  not  ready 
for  them  because  they  had  not  begun  to  solve  many  of  their 
basic  problems  in  controlling  production.  Lists  of  materials 
and  parts  were  not  in  existence.  Production  depended  on  the 
memories  of  people  in  the  company.  Under  such  conditions,  no 
scientific  method  which  needed  data  could  be  implemented 
[ 1 : XI V] . 

The  second  decade  after  World  War  II  has  seen  a  reversal 
of  that  situation.  Supply  caught  up  with  demand  and  low-cost 
high-quality  products  were  available  in  large  quantities. 
Meeting  competition  required  tightly  controlled  factories  and 
most  efficient  use  of  men,  money  and  materials.  The  responsi 
bility  to  achieve  the  necessary  improvements  has  been  given 
to  the  production  and  inventory  control  function  [1:XIV]. 

Production  and  inventory  control  were  separate  functions 
with  conflicting  natures.  Lack  of  data  and  experience  was 
another  problem.  Together  they  created  a  problem  too  serious 
to  ignore. 


The  introduction  of  computers  provided  the  means  for 
solving  many  of  the  problems.  The  use  of  computers: 

1.  Allows  storing  information. 

2.  Enables  processing  and  efficient  use  of  that  information. 

3.  Makes  the  system  more  responsive  because  handling  of 
data,  updating  and  retrieving  are  facilitated. 

4.  Allows  integration  of  both  production  and  inventory 
control . 

First  attempts  to  use  computers  in  production  failed 
[17:3].  The  main  reasons  were: 

1.  Companies  had  failed  to  develop  discipline  in  information 
handling . 

2.  The  system  being  implemented  was  a  mechanized  version  of 
the  manual  system.  Since  the  manual  system  was  never 
taken  seriously  enough  to  work  satisfactorily,  there  was 
no  chance  for  the  computerized  system  to  succeed. 

However,  those  attempts  established  a  sound  foundation  on 
which  better  systems  were  developed,  supporting  initially  only 
parts  of  the  various  functions  of  production  and  inventory 
control.  Later,  integrated  systems  supported,  or  more  accur¬ 
ately,  maintained  the  whole  production  system. 

One  of  the  techniques  which  emerged  and  benefitted  from 
the  use  of  computers  was  the  Material  Requirements  Planning 
(MRP)  method.  This  method,  which  is  used  as  one  module  of 
the  production  and  inventory  control  system,  uses  the  pro¬ 
duction  schedule  as  the  basis  for  inventory  control.  By 
doing  that,  there  are  no  longer  two  different  systems,  but 
one  integrated  system  which: 

1.  Uses  the  same  data  for  both  production  and  inventory 
control. 
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2.  Provides  built-in  mutual  feedback  and  response  in  the 
system  and  no  longer  depends  on  activities  of  separate 
functions  in  the  organization. 

B.  MATERIAL  REQUIREMENTS  PLANNING  CONCEPT 

Material  Requirements  Planning  (MRP) ,  or  Requirements 
Planning  System  (RMS)  as  called  by  others  [1:17.2],  is  a 
technique  for  determining  the  quantities  of  components  that 
will  be  required  to  build  a  product  or  carry  out  a  production 
schedule . 

The  term  "components"  is  usually  used  to  cover  both  sub- 
assemblies  and  parts  from  which  a  product  is  made.  As  far  as 
the  technique  is  concerned,  there  is  no  difference  between 
them  and  the  only  requirement  is  to  know  that  they  are 
required  to  build  the  item  and  in  given  quantities  for 
assembling  one  product. 

The  direct  objective  of  the  system  is  to  generate  require¬ 
ments  in  fairly  precise  time  periods  so  that  the  right  infor¬ 
mation  will  be  available  to  get  the  required  components  into 
the  regular  production  process,  rather  than  using  lists  of 
"hot  items"  to  complete  the  assembly  of  an  order. 

A  manufacturing  environment,  as  opposed  to  maintenance, 
is  the  best  for  implementation  of  this  technique  because  the 
output  of  the  system  is  well  defined  in  terms  of  the  items 
being  produced,  the  components  from  which  they  are  composed, 
their  quantities  and  their  time  schedule.  Only  a  manufactur¬ 
ing  environment  can  provide  the  inputs  that  MRP  needs- -with 
sufficient  accuracy--to  ensure  effective  operation. 


16 


The  MRP  concept  is  described  in  Figure  1.  The  basis  is 
the  master  production  schedule,  which  is  a  ’’given"  to  the  MRP 
system.  The  production  schedule  states  which  products  are 
to  be  produced  and  when.  In  addition  to  that,  the  system 
also  uses  two  other  files: 

1.  Inventory  file  -  This  file  contains  data  about  all 
items  used/produced  in  the  organization.  The  information 
about  each  item  includes  elements  such  as  quantities  (on 
hand,  on  order),  sources  of  supply , price ,  lead  times  and 
associated  costs. 

2.  Bill  of  Materials  file  -  This  file  contains  the 
product  structure  data  for  each  product  which  may  be  produced 
by  the  company.  In  addition  to  quantities  of  subassemblies 
and  parts,  the  file  will  also  contain  numbers  of  drawings  or 
other  documentation  required  in  the  production  process. 


Figure  1:  A  Material  Requirements  Planning  System 
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The  most  important  data  item  in  these  two  files  is  the 
item  identification  number  (part  number) .  This  is  the  common 
field  that  connects  all  files  and  allows  direct  access  to  get 
the  required  information  for  the  computations.  It  is  essen¬ 
tial  to  eliminate  ambiguity  in  those  numbers  on  the  one  hand 
and,  on  the  other,  to  have  meaningful  numbers  which  may 
simplify  operations  of  the  system  and  prevent  mistakes. 

The  process  by  which  requirements  are  determined  is  as 
follows.  First,  the  master  production  schedule  is  used  to 
determine  which  products  will  be  produced  in  the  following 
period.  For  each  order,  relevant  data  from  the  bill  of  ma¬ 
terials  file  is  retrieved  and  added  to  the  "file"  of  required 
materials.  At  this  point,  each  product  is  "exploded"  into 
its  basic  components  and  total  quantities  are  computed  for 
each  item  (part  number). 

It  is  important  to  note  that  the  production  schedule  for 
more  than  one  planning  period  can  be  used.  But  since  the 
time  the  items  will  be  needed  is  very  important  (it  might  be 
very  costly  to  keep  them  when  not  needed),  we  would  like  to 
sum  up  requirements  separately  for  each  period  and  as  close 
as  possible  to  the  day  of  use  as  lead-time  allows.  Adding 
the  requirements  for  all  periods  and  orders  gives  the  "gross 
requirements,"  i.e.,  a  list  Of  all  components  required  to 
carry  out  the  production  schedule. 

When  the  gross  requirements  are  available,  they  are  com¬ 
pared  with  the  information  in  the  inventory  file.  For  each 
item,  the  gross  requirement  is  compared  with  the  total  of 
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quantities  on  hand  and  those  on  order  which  are  due  in  the 
relevant  period.  If  the  gross  requirement  is  greater,  an 
order  should  be  placed.  A  simple  rule  to  determine  the 
order  quantity  suggests  itse If -- order  the  amount  which  is 
missing.  Thus,  it  may  be  that  the  same  item  will  be  required 
for  the  next  period  also.  This  requires  a  more  sophisticated 
rule  which  will  be  discussed  separately. 

The  way  the  process  was  described  is  most  fitting 
when  there  are  no  deviations  from  the  production  schedule. 
Obviously,  this  is  not  always  the  case.  As  it  turns  out, 
the  same  logic  can  also  be  used  in  a  continuous  operating 
environment  (including  deviations  from  schedule)  by  regen¬ 
eration  of  the  requirements  as  described  above.  In  other 
words,  the  updated  production  schedule  is  used  periodically 
to  recompute  the  requirements.  This  process  is  called  a 
Schedule  Regeneration  System  [4:99]. 

Another  way  to  compute  requirements  without  repeating 
all  computations  for  periods  which  were  previously  analyzed 
is  called  the  "Net  Change  Material  Requirements  Planning" 
[4:102].  The  basic  idea  here  is  to  keep  track  of  the  orig¬ 
inal  gross  requirements  for  each  period  and  then  to  compute 
gross  requirements  for  changes  in  the  production  schedule 
as  they  occur  by  adding/subtracting  them  according  to  the 
specific  change  in  the  schedule.  This  results  in  a  new 
gross  requirement  which  has  to  be  compared  to  available 
stocks  (on  hand  and  on  order)  to  give  the  net  requirements. 


19 

t 


1 


The  computation  is  relatively  simple  when  the  change  is 
an  addition  of  a  job,  but  it  becomes  very  complicated  to  keep 
track  and  "to  free"  allocated  materials  when  the  change  is  a 
deletion  of  a  planned  job. 

It  may  seem  that  the  "net  change"  alternative  is  much 
better  than  the  regeneration  system.  This  is  true  if  there 
are  no  changes  in  the  schedule.  But  if  this  is  not  the  case, 
continuous  updating  of  the  whole  data  base  is  required  along 
with  the  necessity  for  incessantly  reacting  to  the  system's 
output.  That  usually  creates  a  "nervous"  reaction  of  the 
system,  i.e.,  order  changes  and  manual  follow-up,  which  is 
more  a  disadvantage  than  an  advantage.  Of  course,  there  is 
always  the  trade-off  between  the  "nervous  reaction"  and  the 
lack  of  reaction  of  the  system.  A  short  (one  month)  cycle 
time  (planning  horizon)  may  provide  a  good  compromise,  thus 
justifying  the  use  of  the  simpler  regenerative  system. 

Figures  2  and  3  describe  the  "regeneration"  and  net 
change  alternatives.  From  the  flow  charts  it  can  be  seen 
that  the  "net  change"  algorithm  is  more  complicated.  But 
if  there  are  only  few  changes  in  the  production  schedule, 
some  work  may  be  saved. 

C.  ASSUMPTIONS  AND  PREREQUISITES 

Introduction  of  an  MRP  system  as  an  inventory  control 
tool  in  a  manufacturing  organization  is  not  just  a  matter 
of  management's  decision.  There  are  some  assumptions  and 
prerequisites  about  the  environment  in  which  MRP  is  to 
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be  implemented.  The  preconditions  for  implementation  of 
MRP  are  listed  below: 


1 .  Existence  of  Automated  Data  Processing  (ADP) 

The  amount  of  work  involved  in  manual  computation  of 
requirements  is  prohibitively  high.  A  manual  MRP  is  imprac¬ 
tical  except  for  very  simple  products.  The  assistance  of 
computers  is  required  for  processing  of  massive  numbers  of 
lower- level  items. 

2 .  Existence  of  a  Master  Schedule,  Bill  of  Materials 

File  and  Inventory  Status  File 

These  files  are  the  basic  input  for  the  MRP  systems 
and  it  is  obvious  that  without  them  the  system  would  not  work. 
But  the  existence  of  such  files  is  not  enough  because  files 
can  have  these  names  and  contain  different  data  than  needed. 
The  Master  Schedule  should  be  stated  in  terms  of  entries  in 
the  Bill  of  Materials  file  (BOM).,  i.e.,  having  a  product  to 
be  produced  allows  access  to  the  Bill  of  Materials  file  to 
get  a  list  of  components  and  quantities  required  to  produce 
that  item.  A  similar  relationship  should  exist  also  between 
the  BOM  file  and  the  inventory  file  to  obtain  the  status  of 
each  component  needed.  The  common  key  here  is  the  Item 
Identification  Code  (IIC). 

3 .  Unambiguous  Item  Identification 

This  is  usually  achieved  through  unique  codes  such  as 
part  numbers.  Although  this  subject  seems  to  be  straight¬ 
forward  and  simple,  it  is  actually  very  difficult  to  maintain 
a  simple  unambiguous  identification  method  when  dealing  with 
hundreds  of  thousands  of  items  coming  from  many  sources. 
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4 .  Data  Integrity 


Files  must  be  kept  updated  and  consistent  with  each 
other.  Changes  in  design  require  changes  in  the  BOM  file  and 
may  result  in  changes  in  quantities  to  be  ordered.  Therefore, 
all  files  should  be  updated  simultaneously  since  changes  in 
one  may  cause  changes  in  another. 

5 .  Known  Lead-times 

At  the  very  least,  there  should  be  estimates  of  lead- 
times  to  allow  reordering  on  time. 

6 .  Availability  of  Components 

All  components  of  a  product  must  be  available  when 
the  production  order  is  released.  Although  this  assumption 
may  not  hold  in  some  cases,  it  may  result  in  simplification 
of  the  MRP  model.  A  more  complicated  version  may  take  into 
account  the  production  schedule  for  a  specific  item  and  allow 
arrival  of  certain  items  during  the  production  process.  This, 
of  course,  is  more  difficult  to  implement  and  the  benefits  are 
outweighed  by  the  problems  it  causes  [4]. 

7 .  Process  Independence 

It  is  assumed  that  there  is  no  interference  between 
different  production  orders.  The  production  master  schedule 
should  incorporate  all  relevant  considerations. 

The  existence  of  all  these  factors  in  an  organization  no 
more  implies  the  applicability  of  the  MRP  model  than  their 
absence  implies  their  inapplicability.  Basically,  an  MRP  is 
"applicable  to  manufacturing  environments  that  are  oriented 
towards  fabrication  of  components"  [4:42],  and  the  problem  of 
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satisfaction  of  preconditions  may  be  solved  if  the  decision 
is  made  to  implement  MRP. 

D.  MRP  SYSTEM  OUTPUT 

What  is  the  MRP  system  expected  to  produce?  Basically, 
every  production/ inventory  control  system  is  expected  to 
provide  the  Inventory  Control  Manager  with  information  that 
will  answer  the  following  three  problems: 

1.  What  to  buy? 

2.  When  to  buy? 

3.  How  much  to  buy? 

The  question  of  what  to  buy  gets  a  straightforward  answer 
from  the  system  by  computations  of  gross  and  net  requirements. 
This  is  a  "simple"  decision  when  the  production  schedule  is 
known  and  the  composition  of  each  product  is  fixed.  Those 
two  factors  are  preconditions  of  the  MRP  system. 

The  problems  of  when  to  buy  and  how  much  to  buy  are  more 
complicated  and  interdependent.  The  decision  may  be  affected 
by  many  external  factors  such  as  sale  prices,  seasonality, 
expected  shortages  because  of  instability  of  the  market  or 
other  similar  factors.  Of  course,  such  factors  cannot  be 
accounted  for  in  a  system  which  runs  according  to  a^prede- 
termined  algorithm  because  they  apply  only  to  specific  items, 
and  the  only  simple  way  to  improve  results  is  to  correct 
manually  the  "proposals"  of  the  system. 

However,  there  are  other  factors  which  determine  the 
quantities  and  timing.  The  basic  factor  is,  again,  the 
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production  schedule.  When  it  is  split  into  specific  tasks, 
an  exact  determination  can  be  made  as  to  how  much  is  required 
at  any  point  of  time.  When  inventory  (on  hand  and  on  order) 
is  compared  against  requirements,  the  result  is  information 
about  definite  quantities  which  are  to  be  available  at  certain 
times.  Consideration  of  lead  times  gives  the  time  for  order¬ 
ing. 

The  decision  whether  to  follow  that  basic  ordering 
schedule  has  still  to  consider  trade-offs  between  ordering 
costs  and  holding  costs  since  the  same  item  may  be  required 
for  more  than  one  period  of  time. 

That  problem  is  solved  by  the  least  unit  cost  method 
[4:511]  which  calculates  the  combined  ordering  and  holding 
cost  per  unit  for  each  period  separately,  for  two  periods 
combined,  for  three  periods,  and  so  on,  and  selects  which¬ 
ever  method  produces  the  lowest  unit  costs. 

Even  though  we  have  discussed  the  output  contents  before, 
it  should  be  recognized  that  the  way  it  will  be  presented 
depends  on  the  user  (and  the  ADP  responsiveness,  of  course!). 
If  the  organization  is  highly  computerized,  and  its  procure¬ 
ment  activities  interact  with  organizations  which  are  also 
highly  computerized,  it  is  likely  that  the  output  will  be 
magnetic  tapes  which  will  contain  all  purchasing  orders. 

These  tapes  will  be  sent  to  the  sellers,  which  in  turn  enter 
them  directly  into  their  automated  system.  (Such  a  method 
is  used  for  procurements  in  the  Israeli  Navy.) 


26 


If  the  system  is  not  that  well  developed,  the  purchasing 
order  containing  all  data  required  to  buy  the  item  will  be 
printed  by  the  computer.  Those  orders  will  then  have  to  be 
reviewed  and  processed. 

The  MRP  system  may  also  produce  many  other  management 
reports.  These  will  usually  concern  specific  problems  which 
exist  in  the  plant.  Typical  reports  of  this  kind  are: 

1 .  Exception  Report 

This  report  presents  exceptional  events  (shortages 
or  unused  inventory)  which  should  be  reviewed  by  someone. 

2 .  Inability  to  Meet  Production  Schedule 

It  may  happen  that  the  production  schedule  was 
determined  without  checking  its  feasibility.  If  so,  the 
schedule  is  impossible  to  follow  because  of  shortages/ long 
lead  times. 

3 .  Inquiries 

These  can  be  helpful  to  the  production  scheduler  to 
prevent  events  which  will  later  appear  as  an  inability  to 
meet  schedules.  Direct  access  to  the  system  files  using  the 
MRP  algorithm  may  help  the  scheduler  to  decide  if  inclusion 
of  a  production  order  in  a  certain  period  is  feasible  or  not. 

The  specific  outputs  should  be  tailored  to  the  needs  of 
the  specific  users  and  the  capabilities  of  the  system  on 
which  MRP  will  run. 
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E.  MRP  AND  CONVENTIONAL  INVENTORY  CONTROL 


There  are  many  good  reasons  for  holding  inventories.  In 
a  manufacturing  environment  the  most  important  reason  is  to 
prevent  production  shutdown  and  allow  smooth  operations. 

Various  techniques  were  developed  to  control  inventories  in 
order  to  optimize  (by  minimizing  total  costs)  operations  of 
the  whole  system. 

Among  the  most  famous  "conventional"  inventory  control 
methods  are  the  following: 

1 .  Perpetual  (Continuous  Review)  System 

Two  inventory  levels  (RO  =  reorder  objective,  ROP  = 
reorder  point)  are  determined  for  each  item.  Inventory  status 
is  reviewed  with  each  transaction  and  when  inventory  reached 
the  ROP  level  a  fixed  quantity  (RO  -  ROP)  is  ordered. 

2 .  Two-Bin  Inventory  System 

This  is  a  simplified  continuous  review  system.  The 
ROP  is  the  quantity  held  in  one  bin  and  the  RO  is  the  quantity 
in  two  bins.  When  one  bin  runs  out  of  stock,  the  quantity  to 
fill  it  is  ordered. 

3.  Periodic  Review 

This  system  reviews  inventory  status  at  fixed  inter¬ 
vals  of  time.  Upon  review,  an  order  is  placed  for  the  quantity 
required  to  bring  inventory  to  RO. 

4.  Optional  Replenishment 

This  is  also  a  periodic  review  system,  except  that 
an  order  will  be  placed  only  if  inventory  is  less  than  a  pre¬ 
determined  quantity  (ROP). 


All  those  policies  use  the  basic  "EOQ  model"  with 
appropriate  adjustments  of  its  assumptions  to  real  life. 

After  selecting  the  model,  the  required  data  is  found  (or 
decided  upon  by  a  "rule-of-thumb")  and  used  to  determine  the 
"order  quantity,"  the  "reorder  point"  and  "reorder  objective." 
Since  the  models  are  used  to  determine  "what,  how  much,  and 
when"  to  buy  in  the  present  and  for  future  use,  all  of  those 
techniques  have  to  use  forecasting  methods  to  estimate  future 
demand  and  that  forecast  (based  on  past  demand)  becomes  the 
basis  for  all  future  operations. 

On  the  other  hand,  MRP  uses  the  production  schedule  which, 
of  course,  provides  a  sound  basis  for  the  computations  and 
promises  smaller  deviations  from  the  plan  to  actual  performance. 

That  advantage  also  has  a  price.  In  order  to  be'  able  to 
operate  an  MRP  system,  a  production  schedule  is  needed  in 
advance  and,  for  each  product,  the  system  has  to  have  an  accur¬ 
ate  bill  of  materials.  This  is  not  the  case  with  the  other 
techniques.  Since  they  do  not  depend  on  a  specific  production 
plan,  they  have  no  need  whatsoever  for  the  master  schedule  or 
bill  of  materials.  All  that  is  needed  is  past  demand  trans¬ 
lated  to  a  forecast  which  helps  to  determine  all  inventory 
levels. 

Another  major  difference  lies  in  the  behavior  of  the 
systems  in  an  environment  of  changing  products.  In  such  a 
case,  conventional  methods  may  cause  a  build-up  of  "dead¬ 
stocks"  and  shortages  in  the  required  new  items,  whereas  MRP 
will  "sense"  that  in  advance  and  stop  ordering  the  items  not 
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needed  and  prepare  the  required  materials.  Because  of  those 
changes,  traditional  techniques  also  suggest  higher  safety 
stocks . 

Generally  speaking,  MRP  will  be  more  responsive  to  pro¬ 
duction  because  of  the  fact  that  it  uses  the  same  plan  and 
objective- -the  production  schedule.  This  is  not  so  with  the 
traditional  methods  which  do  not  consider  it  at  all. 

In  summary,  when  comparing  MRP  to  other  conventional 
production  and  inventory  control  systems,  one  can  identify 
the  following  advantages  and  disadvantages :- 


ADVANTAGES 

DISADVANTAGES 

1.  Based  on  production 
schedule 

1. 

Requires  a  production 
schedule 

2.  Allows  small  or  no 
safety  stocks 

2. 

Requires  a  large,  high 
quality  data  base 

3.  Responsive  to  changes 
in  demand 

3. 

More  complex,  more 
difficult  to  use 

4.  Easily  identifies 
"excess"  items 

4. 

More  difficult  to 
implement 

5.  Does  not  have  to 
keep  historical  data 

This  comparison  shows  that  MRP  has  advantages  as  well  as 
disadvantages.  Before  a  decision  is  made  to  implement  it, 
all  factors  have  to  be  considered  to  determine  that  the 
investment  (money  and  effort)  is  worthwhile. 

F.  IMPLEMENTING  AN  MRP  SYSTEM 

Before  addressing  the  specific  problem  of  implementing  an 

MRP  system,  a  few  words  should  be  said  about  implementation 

of  an  ADP  (Automated  Data  Processing)  system  in  general. 
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The  process  of  implementation  usually  begins  with  the 
very  first  idea  about  system  change  and  it  terminates  when 
the  system  has  been  successfully  integrated  with  the  opera¬ 
tions  of  the  organization.  This  process  involves  the  study 
of  the  new  desired  application,  determination  of  the  objec¬ 
tives,  participation  of  the  future  users  in  the  design  of 
the  "new"  system  and  selection  of  the  steps  and  timetable 
to  change  the  system  from  its  present  configuration  to  the 
desired  one. 

In  this  specific  case,  the  steps  which  will  be  addressed 
are  the  initial  study  prior  to  the  decision  to  proceed  to 
actual  implementation,  the  various  considerations  which 
should  be  discussed  in  that  analysis,  and  the  basic  steps 
towards  implementation. 

The  first  problem  that  should  be  addressed  is  whether 
the  system  is  mature  enough  for  MRP.  The  problem  is  not  one 
of  satisfying  prerequisites,  but  whether  the  change  to  MRP 
is  too  big  for  the  organization.  Nolan  and  Gibson  [3]  iden¬ 
tify  four  stages  in  the  growth  of  EDP  systems  in  terms  of 
the  applications,  EDP  personnel,  and  formal  management  tech¬ 
niques  applied  to  each.  The  four  stages  are:- 

1.  Introduction  of  simple  applications  (such  as  payroll 
and  accounting) . 

2.  Specialization  to  develop  a  variety  of  applications. 

3.  Moratorium  on  new  applications  and  emphasis  on  control. 

4.  Specialization  for  data-base  technology  and  tele¬ 
processing. 

Each  succeeding  stage  requires  more  skills,  more  sophisticated 
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techniques,  and  a  more  mature  environment  than  its  predeces¬ 
sors.  In  order  to  proceed  to  a  higher  stage,  there  should 
be  experience  with  lower-stage  applications  which  naturally 
form  the  basis  for  evolution.  In  the  case  of  MRP  it  will  be 
obvious  that  the  organization  should  have  previous  experience 
'  in  developing  and  using  at  least  separate  systems  for  produc¬ 

tion  and  inventory  control.  At  this  point,  the  problem  will 

I 

involve  "only"  their  integration  and  not  the  much  more  compli¬ 
cated  problem  of  creating  and  integrating  an  advanced  system. 

!  Given  the  environment,  the  existence  of  fundamental  skills 

l 

and  the  acceptance  of  the  decision  and  its  justification,  the 
i 

'  ,  following  actions  are  to  be  taken: 

1.  Analyze  available  and  required  input  for  MRP. 

2.  Design  the  new  MRP  system. 

3.  Identify  required  changes  in  existing  data  files  and 
their  relations  to  other  applications. 

4.  Determine  specific  output  from  the  MRP  system. 

5.  Identify  required  changes  to  existing  software  and 
development  of  new  programs. 

6.  Develop  or  buy  software:  "make  or  buy!' 

7.  Prepare  a  plan  of  how  to  switch  from  one  system  to 
the  other. 

8.  Train  personnel. 

9.  Prepare  a  timetable  for  carrying  out  those  actions. 

10.  Carry  out  that  plan. 

The  first  problem  that  comes  up  after  knowing  what  to  do 
is  deciding  who  will  do  it.  It  is  possible  to  assign  the  job 
'  to  either  an  outside  consultant  or  to  the  organic  EDP  department. 
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Although  bringing  in  an  expert  may  sometimes  cause  troubles 
(especially  dissatisfaction  of  in-house  personnel),  this 
might  be  a  good  solution.  On  the  other  hand,  using  the 
organization's  people  develops  their  skills,  makes  use  of 
their  familiarity  with  the  system  and  prevents  the  problem 
of  later  being  left  to  maintain  a  system  which  was  developed 
by  outsiders. 

Another  problem  is  that  of  designing  the  new  system.  It 
is  desirable  to  have  the  users  participate  in  that  process 
and  contribute  their  knowledge  of  existing  problems  and  sug¬ 
gestions  for  system  improvement.  A  steering  committee, 
composed  of  users  and  EDP  people,  can  serve  as  the  body  to 
gather  essential  information  about  the  old  and  new  systems. 

Two  other  problems  are  interrelated.  These  are  the 
problems  of  changing  existing  software  and  developing  new 
programs.  There  are  MRP  software  packages.  However,  the 
problem  with  these  software  packages  is  that  they  were  not 
designed  for  the  specific  user  that  is  going  to  use  the 
system,  and  since  the  software  package  is  not  flexible,  it 
will  require  changes;  this,  of  course,  should  be  avoided. 

The  same  rationale  should  also  be  used  to  avoid  unnecessary 
expansions.  The  developers  should  concentrate  on  the  minimum 
expansion  and  changes  required  to  accomplish  the  objective 
but  avoid  making  them  too  restrictive  and  inflexible  with 
respect  to  later  developments. 

An  important  factor  in  the  development  of  the  new  system 
is  planning  the  process  of  switching  from  using  the  old  system 
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to  the  new  one.  It  is  highly  desirable  not  to  implement  all 
changes  at  one  time.  It  would  be  better  to  first  change  the 
structure  of  the  data  files  and  to  continue  using  old  programs 
(although  that  also  requires  minor  changes) ,  then: 

1.  Use  converted  data  files  to  develop  and  test  new 
software . 

2.  Run  old  and  new  systems  in  parallel.  Compare  test 
files  and  outputs  with  current  system. 

3.  After  new  software  is  error-free,  stop  using  the  old 
system  and  transfer  to  the  new  one. 

This  sequence  allows  better  testing  and  smooth  switching 
without  having  to  cope  with  many  problems  ("bugs,"  human 
resistance,  lack  of  experience)  in  a  short  and  crucial  period 
of  time. 

Another  decision  that  must  be  made  concerns  which  version 
of  MRP  to  choose:  "net  change"  or  "regenerative"  system.  The 
final  output  is  going  to  be  the  same,  but  the  EDP  problems 
encountered  in  the  net  change  system  are  much  more  complicated. 
It  requires  keeping  old  schedules  and  their  back-up  files, 
generation  of  new  files  for  the  updated  production  schedule 
and,  finally,  their  comparison.  In  addition  to  the  fact  that 
this  data  processing  is  more  complex,  special  attention  is 
also  required  any  time  changes  are  made  to  files  or  programs. 
This  makes  the  system  more  sensitive  to  "bugs"--a  highly 
undesirable  state  of  affairs. 

Another  subject  which  should  be  analyzed  at  this  time  is 
the  introduction  of  advanced  data  base  management  systems. 
Traditional  information  management  is  based  on  keeping  many 
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dedicated  files  of  data  related  to  specific  subjects  such  as 
inventory  status,  finance,  production  schedules,  statistical 
files  or  personnel  records.  That  concept  simplifies  manag¬ 
ing  each  individual  subject  but  creates  duplications  in 
information  reported  and  held,  which  usually  results  in 
conflicts.  On  the  other  hand,  the  new  concept  is  to  have 
one  comprehensive  data-base  holding  all  interrelated  data. 
There  are  special  software  packages  which  support  mainten¬ 
ance  of  data  bases  (IMS,  IDMS,  TOTAL,  ADABAS  and  others)  and 
using  them  may  help  to  create  a  sound  basis  for  a  good  MIS 
(Management  Information  System).  The  planning  period  before 
transition  to  MRP  is  a  very  good  time  to  investigate  the 
possibility  of  moving  to  one  central  data  base.  The  reason 
is  that  MRP  needs  well  coordinated  files  of  inventory  status, 
production  schedules  and  bills  of  materials. 

As  mentioned  earlier,  the  MRP  system  needs  very  accurate 
and  consistent  files  requiring  a  very  careful  processing  of 
data  (especially  the  BOM)  before  operations  begin.  Since  a 
similar  process  is  required  when  converting  to  a  modern 
data-base,  it  is  recommended  to  combine  both  into  one  step 
and  make  sure  that  the  conversion  is  done  carefully  and 
completely. 

A  very  important  factor  which  must  be  kept  in  mind  dur¬ 
ing  the  whole  process  is  the  human  factor.  Implementation 
of  an  MRP  system  is  going  to  affect  the  users  of  the  system 
(inventory  managers,  production  managers  and  other  functions) 
and  the  ones  who  are  responsible  for  implementation  (EDP 
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and  others).  Those  people  must  be  involved  in  the  process, 
asked  to  contribute,  be  trained  in  system  operations  and 
be  made  to  feel  a  part  of  the  system.  The  system  may  require 
changes  in  working  habits  and  procedures  and  their  coopera¬ 
tion  is  essential  for  success. 

G.  CONCLUSIONS 

The  discussion  so  far  has  addressed  a  pure  MRP  system. 

But  does  it  exist  in  a  real  life  situation?  Pure  MRP  is 
unlikely  in  a  real  situation.  There  are  only  a  few  organi¬ 
zations  where  the  MRP  system  will  be  able  to  cover  all 
materials  used.  Since  the  others  must  also  be  managed 
somehow,  a  compromise  must  be  found  between  traditional 
methods  and  this  one.  That  combination  is  necessary  espe¬ 
cially  in  organizations  whose  work  is  not  pure  production, 
even  though  the  work  may  be  of  a  repetitive  nature.  This 
can  be  the  case  of  a  shipyard  or  a  repair  facility  which 
also  produces  some  items. 

The  nature  of  repairs  is  that  there  is  not  an  accurate 
"Bill  of  Materials"  for  repair  of  a  given  item,  although 
averages  and  standard  deviations  may  help  represent  the  case 
as  "pseudo-production."  This  is  particularly  true  about 
inexpensive  spare  parts  (bolts,  nuts,  fuses  or  other  "con¬ 
sumables")  which  have  a  high  total  demand,  but  also  high 
deviations  in  requirements  for  repair  of  certain  items. 

The  best  way  to  act  in  such  an  environment  is  to  combine 
MRP  with  the  regular  EOQ  models.  This  will  require  classifi¬ 
cation  of  items  according  to  the  system  which  is  used  to 
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control  them.  Items  which  are  inexpensive  and  "high-movers" 
can  be  controlled  by  the  simple  EOQ  model,  whereas  more 
expensive  items,  which  are  not  common  to  many  systems  and 
have  low  (and  discrete)  demand,  can  be  treated  by  the  MRP 
system. 

It  may  appear  that  this  combination  is  more  complicated, 
but  it  turns  out  that  the  input  required  for  MRP  already 
provides  the  input  for  the  simple  EOQ  model  and  the  overhead 
from  having  another  module  is  overridden  by  the  extra  benefits 
that  the  combination  gives. 


37 


III.  SUPPLY  SUPPORT  OF  NARF  ALAMEDA 


The  intent  of  this  chapter  is  to  describe  the  "present" 
supply  support  of  NARF  Alameda,  the  concept  that  underlies 
this  system,  the  data-base  and  computer  resources  used  in 
this  process,  the  weak  points  of  the  system  and  elements  that 
require  improvement. 

Phase  II  of  the  San  Francisco  bay  area  SER  is  now  underway 
and  it  is  somewhat  difficult,  however,  to  be  exact  in  this 
description  of  the  "present"  system  because  of  the  consolida¬ 
tion  and  the  continual  changes  resulting  from  it.  There  will 
be  an  attempt  to  distinguish  between  activities  which  existed 
prior  to  consolidation  and  those  resulting  from  consolidation. 
If  everything  goes  according  to  the  original  schedule  [7:19], 
the  present  system  with  temporary,  pre-NISTARS  improvements, 
will  last  throughout  April  1981. 

Figure  4  depicts  both  pre  and  post  consolidation  requisi¬ 
tion  channels  of  NARF  Alameda  and  provides  a  framework  for 
the  description  to  follow. 

A.  CONCEPT  AND  OPERATION 

The  concept  applied  for  the  supply  support  of  NARF  Alameda 
is  the  Area  Support  Concept  [9:111-15].  This  concept  is  gen¬ 
erally  employed  in  geographical  areas  surrounding  NSC's  and 
NSD's  where  the  customer  activities  are  nearby.  According  to 
this  concept,  the  customer--in  this  case  the  NARF--does  not 
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After  Consolidation 
Before  Consolidation 


Figure  4:  NARF's  pre/post  consolidation  requisition 
flow 
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stock  items  [9] --except  nonstandard  items  or  expense  item 
material -- and  whenever  items  are  needed  they  have  to  be 
requisitioned  through  the  requisitioning  channels. 

1 .  Pre -Consolidation  Support 

Prior  to  the  consolidation,  the  NARF  shops  had  three 
sources  of  supply: 

a.  The  NARF's  NIF  (Navy  Industrial  Fund)  Stores. 

b.  NAS  Alameda- -for  aviation  items. 

c.  NSC  Oakland--for  other  items. 

Each  of  these  sources  has  different  stocking  policies  and 
procedures  to  determine  the  items  to  stock,  order  quantities, 
and  reorder  points. 

a.  NIF  Stores  Items 

Items  stored  in  the  NARF's  storerooms  are  deter¬ 
mined  by  the  NARF's  material  planning  personnel.  However, 
approval  for  establishing  items  in  the  Alameda  stores  is 
restricted  to  material  section  heads  or  higher.  The  material 
planners  are  allowed  to  establish  NIF  stores  items  with  mini¬ 
mum  demand  frequency  of  six  per  quarter  and  maximum  unit  price 
of  $25.  Order  and  reorder  quantities  are  determined  by  the 
material  planner  using  his  experience  and  the  technical  data 
(drawings)  available. 

A  major  portion  of  the  material  support  for  the 
industrial  operation  is  provided  by  the  Pre -Expended- Bin 
(PEB)  operation.  It  contains  high  usage,  low-priced  items 
that  have  been  expended  from  stock  records  and  charged  to 
overhead  at  the  NARF.  The  NARF  also  maintains  physical 
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records  of  materials  provided  by  customers  for  use  on  their 
own  jobs. 

The  NIF  Store  operation  is  basically  a  manual 
operation.  As  a  result,  there  is  not  any  (recorded)  historical 
demand  data  to  be  used  for  more  intelligent  demand  forecasting 
or  inventory  control.  This  is  going  to  change  with  the  intro¬ 
duction  of  the  Naval  Air  Industrial  Material  Management  System 
(NIMMS)  that  will  be  described  later  on. 
b.  NAS  Alameda 

Before  the  consolidation,  NAS  Alameda  supported 
the  NARF  as  a  wholesale  customer  for  IR  Cog  material  and  as 
a  retail  customer  for  the  9  Cog  and  SPCC  managed  items.  The 
wholesale  stock  levels  were  maintained  by  ASO.  Unfilled 
NARF  requirements  were  transmitted  to  ASO  for  referral,  pro¬ 
curement  or  other  action  as  required. 

On  the  other  hand,  the  NARF's  demand  for  retail 
material  was  provided  for  by  the  VOSL  (Variable  Operating  and 
Safety  Level)  model.  The  disadvantage  of  VOSL  in  this  case 
is  that  it  uses  historical  demand  to  forecast  future  require¬ 
ments.  In  reality,  NARF  demand  is  dependent  on  the  production 
schedule  of  the  NARF.  For  example,  during  the  second  quarter 
of  FY  '79  the  Point  of  Entry  CPOE)  supply  effectiveness  (i.e., 
the  ratio  of  requisitions  that  were  filled  and  the  total  number 
of  requisitions  entered  into  the  system)  of  NAS  Alameda  was 
53.2  percent  for  IR  Cog  expense  items,  74.4  percent  for  9  Cog 
items  and  55.7  percent  for  SPCC  managed  items  [21].  These  low 
figures  appear  to  be  a  result  of  the  model  discrepancy,  as 
described  above. 
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c.  NSC  Oakland 

NSC  Oakland  was  NARF  Alameda's  source  of  supply 
for  the  9C,  9D,  9G ,  9N  and  9Z  Cogs.  NSC  Oakland  is  a  Special 
ized  Support  Depot  (SSD) ;  that  is,  an  activity  with  a  special 
ized  mission  as  to  the  type  of  material  or  scope  of  support. 
Its  stock  replenishment  is  centrally  controlled  by  the 
cognizant  Defense  Logistic  Agency  (DLA)  Item  Manager  (IM)  . 
Stock  replenishment  is  based  on  historical  demand. 

Similar  to  the  situation  at  NAS  Alameda,  this 
policy  does  not  seem  to  fit  the  case. 

2 .  Post-Consolidation  Support 

Phase  II  of  the  consolidation  (administrative  consol¬ 
idation)  is  currently  being  implemented  after  phase  I  (plan¬ 
ning)  has  been  completed.  Its  most  significant  effect  is  the 
fact  that  NAS  Alameda  no  longer  supports  the  NARF,  and  the 
only  external  source  of  supply  is  now  NSC  Oakland.  It  also 
becomes  the  replenishment  source  for  the  NIF  Stores  inventory 
As  mentioned  earlier,  this  period  is  an  intermediate 
period  that  will  last  until  the  installation  and  integration 
of  the  NISTARS  at  NSC  Oakland  and  ASKARS  at  NARF  Alameda, 
a.  NIF  Stores 

The  consolidation  has  no  direct  effect  on  the  NIF 
Stores  except  that  their  stock  replenishment  will  be  now  only 
from  NSC  Oakland  (NSCO)  and  not  from  NSCO  and  NARF  Alameda. 
However,  the  implementation  of  NIMMS  requires  the  appropriate 
interfaces  to  NISTARS  and  ASKARS  so  that  savings  from  the 
improved  control  and  usage  of  recorded  data  would  not  be 
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degraded  by  additional  work  (caused  by  old  processes)  when 
items  are  replenished,  stocked  or  retrieved. 

The  NIMMS  software  package  is  designed  to  process 
inventory  transactions  and  does  this  through  an  Inventory 
Balance  File  and  a  Transaction  file.  Those  files  are  used 
to  produce  management  reports,  especially  the  "NIF  Retail 
Store  Stratification"  report  in  which  reorder  levels  are 
updated,  and  the  "Automatic  Replenishment" -- which  uses  those 
levels  and  the  on-hand  quantity. 

The  function  of  automatic  replenishment  requires 
an  interface  to  ASKARS  and  NISTARS,  to  obtain  information  on 
the  requisitions'  status  in  order  to  determine  when  replenish¬ 
ment  is  required,  and  later,  to  direct  the  material  for  stock¬ 
ing  in  ASKARS. 

b.  NSC  Oakland 

The  change  in  the  organizational  structure  by 
itself  would  not  improve  the  availability  of  items  required 
by  the  NARF.  In  fact,  there  are  many  items  that  were  not 
carried  by  NSC  Oakland  before  the  consolidation  and  will  have 
to  be  carried  afterwards. 

Items  for  the  NARF  will  be  separated  from  the 
regular  NSC  stock  f sometimes  physically  and  sometimes  only 
logically)  into  a  Ready  Supply  Store  (RSS).  The  range  and 
depth  of  the  RSS  stock  will  eventually  trade  the  actual  de¬ 
mand  instead  of  forecasting  demand  only  according  to  histor¬ 
ical  demand.  The  actual  demand  will  be  forecasted  by  the  MRP 
model  using  the  BOM  information  and  the  production  schedule. 
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The  implementation  of  RSS  and  MRP  concepts  will 
take  place  in  three  phases :- 

1.  Establishing  the  RSS  and  its  initial  stock  levels,  as 
described  below. 

2.  Change  RSS  operation  to  level  settings  by  "temporary" 
MRP . 

3.  Approval,  implementation  and  operation  with  the  pro¬ 
posed  MRP  system. 

Since  the  temporary  MRP  data  base  and  software 
were  not  ready  on  11  November  1979  (the  day  of  establishing 
the  RSS)  a  "rule  of  thumb"  was  used  [19]  to  determine  the 
initial  RSS  stock.  The  procedure  to  set  those  levels  was 
as  follows :- 

1.  Identify  all  customer  orders  that  will  be  worked  in 
FY  '80. 

2.  Generate  a  list  of  "candidate"  NIIN'sby  searching  the 
NARF's  POE  demand  for  those  customer  orders  in  the 
last  three  quarters. 

3.  Delete  from  the  list  any  NIIN  that  does  not  belong 
to  one  of  the  following  Cogs:  9Z,  9N,  9G,  9D,  9C. 

4.  Add  items  for  the  following  four  special  support 

programs:  F62  engine,  TF34  engine,  50K-17  engine  and 

A6E  aircraft. 

5.  For  all  items  in  that  list,  compute  the  NAS  Alameda 
protected  quantity  (stock  to  support  the  NARF  and 
squadrons  for  one  quarter,  computed  by  VOSL) . 

6.  Split  the  protected  quantity:  85  percent  for  NARF  and 
15  percent  for  retail  protected  quantity.  These 
percentages  were  determined  by  the  share  of  the  NARF's 
requisitions  out  of  all  requisitions  filled  by  NASA. 

7.  Compute  the  initial  RSS  quantity  for  the  item  as  the 
maximum  of  0  and  the  difference  between  the  NAS  Alameda 
on -hand  balance  and  the  retail  protected  quantity. 

8.  Write  an  AOA  ("fill  or  kill")  requisition  automatically 
for  all  items  with  a  positive  initial  RSS  quantity  (for 
that  quantity) . 
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The  reasons  for  using  that  simple  procedure  were 
ma  ,ily  the  short  time  available  and  the  "need"  to  prevent  its 
decapitalization  to  DLA  owned  stock  at  NSCO.  It  also  saved 
a  lot  of  time  by  generating  the  requisitions  by  software  and 
not  manually. 

The  introduction  of  the  RSS  required  changes  in 
the  NARF's  requisitioning  procedure  to  NSC.  Instead  of  merely 
submitting  a  requisition  to  NSC,  the  NARF  now  has  to  first 
determine  if  the  item  is  available  from  the  RSS  stock.  If 
so,  the  requisition  will  be  directed  to  the  RSS;  otherwise, 
it  will  be  referred  directly  to  NSCO  wholesale  stock.  A 
terminal  communication  network  allows  on-line  inquiries 
against  both  RSS  and  wholesale  stock. 

The  integration  of  the  temporary  MRP  system  will 
occur  gradually  as  that  software  and  data  base  are  expanded. 

The  requirements  for  the  second  quarter  of  FY80,  generated 
by  MRP,  will  cover  only  the  F/E  and  engine  programs.  The 
requirements  for  the  other  programs  will  be  determined  manually 
and  added  to  those  generated  by  MRP.  Afterwards,  the  require¬ 
ments  for  the  third  quarter  of  FY80  will  be  generated  by  MRP 
for  all  programs.  These  requirements  will  be  checked  and 
updated  manually  by  the  material  planners  before  submission 
to  NSC  Oakland. 

The  process  of  determining  and  submitting  require¬ 
ments  to  NSCO  can  be  further  improved  with  the  implementation 
of  the  proposed  MRP  system. 
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B.  AUTOMATED  DATA  PROCESSING  OVERVIEW 

As  described  earlier,  prior  to  the  consolidation  both 
NSC  Oakland  and  NAS  Alameda  were  involved  in  supply  support 
of  NARF  Alameda.  One  of  the  implications  of  having  two 
"suppliers"  was  that  both  activities  had  to  carry  out  similar 
inventory  management  functions,  i.e.,  both  activities  had  to 
process  separately  the  same  kind  of  transactions  and  maintain 
the  same  kind  of  files,  both  referring  to  the  same  customer-- 
NARF  Alameda.  Both  NSC  Oakland  and  NAS  Alameda  use  the  same 
inventory  management  system:  the  Uniform  Automated  Data  Pro¬ 
cessing  System- -Stock  Point  [UADPS-SP].  After  the  consoli¬ 
dation,  NSC  Oakland  becomes  the  only  direct  supplier  for  the 
NARF . 

With  respect  to  data  processing,  it  means  that  NSCO's 
data  processing  department  will  do  most  of  the  data  processing 
of  data  relating  to  the  NARF.  However,  in  addition  to  pro¬ 
cessing  done  by  NSCO,  there  will  be  some  inventory  management 
data  processing  by  the  NARF  itself.  This  may  involve  running  the 
MRP  application  and  generating  the  requirements  to  be  sub¬ 
mitted  to  the  NSCO. 

This  section  describes  NSC  Oakland's  data  processing 
systems.  Details  on  data  processing  and  DP  equipment  at  NARF 
Alameda  are  given  in  the  chapter  describing  the  temporary 
MRP  application. 

1 .  Data  Processing  Equipment  and  Applications 
at  N§C  Oakland 

NSC  Oakland  is  one  of  several  of  the  Navy  activities 
using  the  Uniform  Automated  Data  Processing  System- -Stock 
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point  (UADPS-SP) .  UADPS-SP  is  the  standard  software  package 
used  by  Navy  stock  points  to  carry  out  the  various  inventory 
management  functions.  However,  inventory  control  is  only  one 
of  the  applications  run  by  NSCO's  Data  Processing  Department 
(DPD)  as  UADPS-SP.  The  major  applications  are  the  fo  owing 
ones :  - 

1.  Inventory  Control. 

2.  Requisition  Control. 

3.  Financial  Inventory  Control. 

4.  Stores  Accounting. 

5.  Civilian  Employees  Payroll. 

6.  Supply  Overhaul  Assistance  Program. 

7.  Labor/Cost/Allotment  Accounting. 

8.  Procurement  and  Procurement  Accounting. 

The  list  of  applications  is  so  long  mainly  because 
UADPS-SP  was  developed  during  the  early  1960 's,  and  although 
it  underwent  several  improvements  and  modifications,  the 
system  is  still  using  concepts  and  equipment  from  that  period. 
As  a  result,  instead  of  having  one  integrated  system,  the 
"system"  is  composed  of  a  set  of  related  applications  that 
use  many  traditional  files  (as  opposed  to  an  integrated  data¬ 
base  and  a  data-base  management  system),  many  old-fashioned 
programs  and  processing  runs  and  a  variety  of  data  processing 
equipment.  Appendix  A  gives  a  list  of  selected  UADPS-SP  files 
which,  as  mentioned  earlier,  are  only  part  of  the  data-base. 

In  addition  to  the  above  list  of  applications,  the 
DPD  runs  also  a  telecommunication  system.  The  network  has 
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terminals  in  the  San  Francisco  bay  area  and  at  other  Navy 
facilities,  and  provides  inquiry  services  relating  to  inven¬ 
tory  and  requisitions  and  data-entry  for  material  storage/ 
receiving  and  for  procurement. 

The  hardware  consists  mainly  of  a  dual  system:  a 
Burroughs  B-4800  CPU  and  a  Burroughs  B-3500,  a  peripheral 
switching  unit  that  helps  sharing  the  peripheral  devices  by 
both  CPU's  and  thereby  improve  their  utilization.  The 
B-3500  is  used  with  a  front-end  processor  (Burroughs  B-874) 
for  communication,  whereas  the  B-4800  handles  the  batch¬ 
processing  applications.  The  non- inventory  control  applica¬ 
tions  are  handled  by  a  Honeywell  H200  computer,  a  Wang 
computer  and  an  IBM  360/20  card- system.  Most  of  the  termin¬ 
als  used  in  the  communication  network  are  Burroughs  products 
(TD-800,  TD-700,  TC-500).  Until  recently  some  non-Burroughs 
terminals  were  also  connected  to  the  network  (Zentec  and 
Hazeltine) .  The  system  also  includes  three  line  printers, 
two  card  readers,  two  card-punchers  and  a  variety  of  conven¬ 
tional  equipment. 

The  DPD  operates  in  three  shifts,  seven  days  a  week 
and,  according  to  the  DPD  director,  the  equipment  is  utilized 
to  90  percent  or  more  of  its  capacity.  The  major  implication 
of  this  fact  is  that  it  is  very  difficult  to  add  new  applica¬ 
tions  to  the  system  and  also  that  equipment  failures  can 
generate  severe  backlogs  in  the  system. 

Another  import  aspect  of  the  operation  of  the  DPD 
is  that  it  usually  does  not  develop  its  own  software. 
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Only  applications  that  are  simple  and  local  in  nature  are 
written  by  local  programmers. 

2 .  The  Inventory  Management  Subsystem 

The  UADPS  for  stock  points  is  divided  into  three 
subsystems,  each  consisting  of  one  or  more  applications  and 
each  serving  a  logical  group  of  stock  point  functions.  The 
three  subsystems  are:- 

1.  Activity  Management  (Designator  A). 

2.  Inventory  Management  (Designator  I). 

3.  Data  Processing  Environment  (Designator  D) . 

The  highest  level  of  interface  between  the  functions 
performed  at  a  stock  point  and  the  UADP  System  is  at  the 
application  level.  In  UADPS  terminology,  the  term  "appli¬ 
cation"  is  arbitrarily  used  to  define  those  data  processing 
actions  which  supplement  the  manual  actions  necessary  to 
carry  out  a  given  function.  Consequently,  what  is  usually 
referred  to  (not  in  UADPS)  as  inventory  management  (applica¬ 
tion)  is  in  UADPS  terminology  a  subsystem  and  is  composed  of 
several  applications. 

Each  application  is  subdivided  into  a  variable  number 
of  operations  which  are  defined  as  one  or  more  ADP  runs  per¬ 
formed  to  produce  a  given  major  product  or  result,  e.g., 
produce  a  given  report,  process  a  specific  type  of  transaction, 
etc.  The  large  numbers  of  applications  and  operations,  and 
the  fact  that  those  operations  are  scheduled  manually,  explain 
why  it  is  so  difficult  to  run  the  system. 
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The  following  applications  comprise  the  inventory 
management  subsystem: 

1.  Customer  Information  (designator  IA)  involves  the 
actions  required  to  provide  information  of  any  nature 
to  customer  activities. 

2.  Receipt/Due  (designator  IB)  involves  those  actions 
beginning  with  the  establishment  of  a  due- in  through 
receipt  of  proof  of  storage. 

3.  Issue/Demand  Processing  (designator  IC)  begins  with 
the  receipt  of  demand  document  and  continues  through 
the  preparation  of  a  referral  order  or  issue  document/ 
picking  ticket  and  proof  of  issue. 

4.  Inventory  Control  (designator  ID)  includes  manipulation 
of  demand  data  to  set  stock  levels,  determining  replen¬ 
ishment  requirements,  reconciling  replenishment  back 
order  requests,  and  processing  replenishment  documents. 

5.  Quality  Control  (designator  II)  involves  stock  record 
accuracy,  including  location  audit,  physical  inventory 
and  physical  inspection  of  stock. 

6.  Disposal  (designator  IM)  involves  computation  of  excess 
quantities  and  follow-up  on  disposal  and/or  shipment 

of  excesses. 

7.  Automated  Ready  Supply  Stores  System  (designator  IN) 
involves  the  supply  and  financial  management  and 
recordkeeping  functions  for  RSS.  NARF  Alameda’s  MRP 
system  will  have  to  interface  with  this  application. 

8.  Records  Maintenance  (designator  IP)  involves  those 
actions , necessary  to  maintain  accurate  mechanized 
records. 

9.  Repairables  Management  (designator  IR)  involves  the 
actions  necessary  to  induct  NRF I  (Not  Ready  for  Issue) 
material  into  a  repair  facility  and  to  maintain 
control  throughout  the  repair  cycle. 

3.  Data  Files 


The  inventory  management  subsystem  uses  and  updates 

most  of  the  files  in  the  data  base.  Of  special  importance 

are  the  Master  Stock  Item  Record  (MSIR)  file  and  the  files 

which  contain  customers'  requisitions:  the  Requisition  Status 

File  (RSF)  and  Demand  History  File  (DHF) . 
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The  MSIR  is  a  variable  length,  direct  access  record 
containing  stock  status  data  for  each  item  carried  in  stock 
at  the  activity.  Data  elements  relevant  to  identification, 
control,  storage,  and  quantities  of  the  item  are  stored  in 
a  header  record.  As  stock  data  accumulates  (demand  history, 
demand  frequency,  due-in  quantities  and  others),  it  is  added 
in  the  form  of  trailers.  The  access  key  to  the  MSIR  is  by 
Federal  Item  Identification  Number  (FIIN). 

The  RSF  contains  randomly  stored  records  of  customers' 
requisitions  (stored  and  accessed  by  document  number)  and  of 
the  supply  action  that  has  been  taken  by  the  stock  point  to 
satisfy  the  requisitions.  The  RSF  covers  the  most  recent 
three  months. 

The  DHF  contains  the  same  kind  of  information  as 
the  RSF  but  covers  the  previous  six  months.  Records  that 
are  deleted  from  the  RSF  are  transferred  to  the  DHF. 

The  various  operations  that  comprise  the  inventory 
management  subsystem  are  run  on  various  frequencies  from 
daily  runs  to  weekly,  monthly,  quarterly  and  annual  runs. 

The  files  are  updated  on  a  daily  basis  although  certain  up¬ 
dates  occur  less  frequently.  An  important  disadvantage  in 
the  design  and  in  the  way  the  system  is  run  is  the  fact  that 
many  different  programs  (operations)  update  the  same  files. 
This  makes  it  very  difficult  to  control  the  system,  to  ensure 
the  correct  sequence  of  file  updates  and,  especially,  to  re¬ 
produce  a  previous  state  of  the  system  files  in  case  of  a  bad 
file  entry  or  detection  of  a  software  error  after  the  faulty 
program  was  used  for  a  while. 
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4.  UADPS  and  MRP 


From  the  discussion  thus  far,  it  should  be  clear 
that  UADPS  and  the  MRP  applications  have  two  different  spon¬ 
sors.  UADPS  is  run  by  NSC  Oakland  whereas  NARF  Alameda  will 
develop  and  benefit  from  implementation  of  MRP.  However, 
since  vital  information  is  available  at  NSC  Oakland's  DPD 
and  since  it  will  do  the  computerized  inventory  management  of 
the  inventory  reserved  for  the  NARF  (in  the  RSS's),  it  is 
necessary  to  establish  an  appropriate  interface  between  the 
systems . 

The  areas  in  which  the  UADPS  and  MRP  systems  need 
coordination  and/or  use  the  same  data  are: 

a.  Inventory  Status  File 

MRP  needs  an  inventory  status  file  for  determin¬ 
ing  requirements  and  for  other  data  elements  on  each  item 
(such  as  lead  time).  This  information  is  contained  and  up¬ 
dated  in  the  MSIR. 

b.  Bill  of  Materials 

Since  maintenance  work  involves  variable  quanti¬ 
ties  of  components  for  doing  the  same  work,  the  bill  of 
material  file  of  an  MRP  system  has  to  be  created  and  updated 
according  to  historical  usage  rates  of  components,  when 
doing  specific  jobs.  Computing  usage  rates  involves  identi¬ 
fication  of  the  quantity  of  items  that  were  repaired/produced 
on  a  specific  job  order,  and  the  components  that  were  required 
to  accomplish  the  job.  The  first  piece  of  data  is  available 
at  the  NARF  whereas  usage  information  is  contained  in  the 

requisition  files--both  RSF  and  DHF. 
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c.  RSS  Stock  Levels 

One  of  UADPS's  functions  is  to  set  and  update 
stock  levels  for  RSS.  UADPS  uses  the  historical  demand  as 
the  basic  data  for  setting  those  levels.  It  will  be  necessary 
to  override  the  "regular"  level  settings  by  the  requirements 
generated  by  MRP. 

These  problems  will  be  further  addressed  in  the 
next  chapter. 

C.  EVALUATION  AND  CONCLUSIONS 

The  Area  Support  Concept  employed  in  support  of  NARF 
Alameda  provides  a  significant  advantage  because  of  the  cen¬ 
tralized  management,  stocking  and  procurement  of  supplies 
("economics  of  scale").  However,  the  common  method  applied 
to  forecast  demand  may  have  an  adverse  effect  on  the  effec¬ 
tiveness  of  supporting  the  NARF.  The  VOSL  model  assumes  that 
demand  in  the  future  will  behave  the  same  as  in  the  past  but 
that  may  not  be  the  case  for  the  NARF  because  its  material 
requirements  are  driven  by  a  production  schedule  which  varies 
from  one  quarter  to  another.  This  problem  can  best  be  solved 
by  employing  the  MRP  model. 

The  NIF  store's  inventory  is  and  will  continue  to  be 
managed  by  a  totally  different  system.  The  fact  that  the 
items  carried  in  the  NIF  stores  are  fast  moving,  low  cost 
items  seems  to  suggest  their  exclusion  from  the  MRP  system 
at  least  at  the  beginning.  Also,  the  fact  that  their  demand 
is  more  stable  justifies  the  use  of  a  conventional  model. 
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However,  the  time  may  come  when  the  MRP  system  will  be  suffi¬ 
ciently  reliable,  when  it  may  be  more  cost  effective  to  have 
only  one  system  for  managing  the  NARF's  material  requirements. 
Including  this  inventory  in  the  MRP  system  will  require  adding 
these  items  to  the  BOM  file. 

As  to  ADP,  it  seems  that  NSCO's  DPD  may  not  be  the  activity 
to  run  the  MRP  application.  The  out-dated  equipment  and  the 
large  variety  of  applications  that  are  presently  run  seem  to 
be  sufficiently  complicated  to  manage  so  that  perhaps  the  NARF 
should  run  the  MRP  system  and  provide  the  end  results  - -namely , 
the  material  requirements  and  RSS  stock  levels,  to  NSCO's  DPD. 
However,  possible  incompatibility  of  the  Burroughs  equipment 
at  NSC  with  the  NARF  system  may  require  appropriate  transfor¬ 
mations  of  data  to  allow  use  of  information  maintained  by 
NSCO  (MSIR  information  and  recognition  data)  in  the  NARF 
sys  tem. 
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IV.  THE  TEMPORARY  MRP  APPLICATION1 

When  the  idea  to  implement  MRP  at  NARF  Alameda  was 
proposed,  it  seemed  that  before  doing  the  full-detail  design 
of  the  application  it  would  be  appropriate  to  carry  out  an 
experiment  in  which  the  MRP  technique  would  illustrate  the 
extent  to  which  it  could  actually  forecast  the  NARF's  mater¬ 
ial  requirements.  But,  as  people  got  more  involved  in  the 
subject  and  obtained  a  better  understanding  of  the  work 
involved,  the  500  Department  (the  department  in  charge  of 
this  application)  decided  to  redefine  the  objective  to  design 
the  implementation  of  a  s imple  MRP  system  that  would  take  a 
short  time  to  implement,  would  be  capable  of  demonstrating 
the  technique  for  the  purpose  of  comparison  with  the  present 
system  and  would  provide  operational  generation  of  NARF's 
material  requirements  until  ASKARS  and  NISTARS  are  installed. 

It  was  realized  that  there  is  a  trade-off  between  sim¬ 
plicity,  required  effort  and  the  length  of  the  implementation 
period,  and  the  quality  of  the  results.  Unfortunately,  the 
NARF's  regular  personnel  had  to  carry  out  the  project  with 
almost  no  additional  people  (their  mission  does  not  include 
software  development!);  the  short  time  available  made  all 
other  alternatives  infeasible.  It  is  believed,  however, 

^Based  on  personal  interviews  and  discussions  with 
LCDR  W.  P.  Benefiel,  from  NARF  Alameda. 
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that  even  this  "low  quality"  product  will  produce  a  supply 
effectiveness  better  than  that  of  the  present  system. 

This  chapter  describes  the  "temporary"  MRP  application, 
the  functions  it  performs,  the  data-base  and  software  modules, 
the  creation  of  the  initial  data-base  and  the  interface  to 
UADPS  and  NSC  Oakland. 

A.  SYSTEM  OVERVIEW 

The  temporary  MRP  application  was  developed  and  is  run 
on  the  ADP  system  of  the  production  planning  and  control 
department  (500)  at  NARF  Alameda.  The  system  consists  of 
a  PDP  11/70  CPU  with  an  IAS  (Interactive  Application  System) 
general  purpose  operating  system,  512  KB  memory,  2  RP06  300 
MB  disk  drives,  1  RS04  swapping  disk,  2  TE16  tape  drives, 

1  LPU  line  printer,  1  CRU  card  reader,  28  hard  wired  termin¬ 
als  and  some  other  "dial-up"  terminals.  This  system  is  used 
to  run  several  local  NARF  applications  and  can  easily  handle 
the  MRP  application. 

The  major  objective  of  implementing  the  temporary  MRP 
system  is  to  generate  a  forecast  of  the  NARF's  quarterly 
material  requirements.  These  requirements  are  to  be  used 
as  stock  levels  for  the  RSS. 

Secondary  objectives  are  to  provide  the  NARF's  material 

% 

planners  with  accurate  data  that  will  assist  them  in  doing 
their  job,  especially  when  ordering  materials  for  unscheduled 
jobs.  The  system  is  also  to  provide  some  exception  reports 


on  consumption  of  materials  to  allow  analysis  of  these  jobs 
and  the  reason  for  the  exceptional  consumption. 

The  system  produces  three  major  outputs: 

1 .  Material  Requirements 

These  are  only  recommendations.  They  are  checked 
and  updated  by  the  material  planners  if  they  do  not  agree 
with  the  systems  recommendations. 

2 .  Answers  to  Queries 

The  system  provides  a  set  of  queries  on  the  BOM  file 
and  the  gross  requirements  forecast.  This  information  is 
used  routinely  by  the  material  planners. 

3.  Bill  of  Material  Listing 

The  listing  is  designed  to  provide  the  same  basic 
information  as  the  queries  but  requires  the  material  planner 
to  do  the  material  requirements  computation  manually.  The 
report  is  used  as  a  back-up  to  the  communications  network 
and  also  for  those  material  planners  that  do  not  have  a 
terminal . 

The  inputs  to  the  system  consist  of  requisitioning  data 
from  UADPS  and  induction  data  (quantities  of  items  reraired) 
from  NARDAC  (Navy  Regional  Data  Automation  Center)  that  are 
used  to  update  the  BOM  file  and  the  workload  schedule  from 
ASO  which  is  later  used  to  translate  the  schedule  into  re¬ 
quirements.  Another  input  is  the  information  that  relates 
IIC's  (Item  Identification  Codes)  to  FIC's  (Family  Identi¬ 
fication  Codes)  which  is  required  for  translation  of  the 
workload  schedule- -which  is  by  FIC's--into  a  schedule 
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by  IIC's.  The  inputs  to  the  system  are  all  external  data 
although  it  is  originated  by  or  refers  to  the  NARF. 

A  major  element  that  is  missing  in  this  MRP  application 
is  the  inventory  status  file  which  has  to  be  used  for  deter¬ 
mination  of  net  requirements.  The  reason  for  that  is  that 
this  application  is  used  only  to  determine  gross  requirements 
which  are  needed  as  RSS  stock  levels.  Therefore  the  computa¬ 
tion  of  net  requirements  does  not  have  to  take  place  in  this 
system  but  rather  in  UADPS-SP. 

The  environment  in  which  MRP  is  run  includes  both  time¬ 
sharing  and  batch  processing.  The  requirements  generation 
is  run  on  a  quarterly  basis.  The  run  includes  first  an 
update  of  the  files  and  later  the  generation  of  the  outputs. 
This  fact  raises  some  questions  about  the  need  for  on-line 
inquiries.  But  it  turns  out  that,  since  the  equipment  was 
already  there  and  was  underutilized,  it  would  be  nice  to 
provide  this  service. 

Figure  5  describes  the  information  network  and  the 
operation  of  the  MRP  application. 

B.  MRP  DATA-BASE 

The  data-base  for  the  MRP  application  consists  of  three 
master  files  and  two  index  files: 

1.  The  bill  of  materials  file  (BOM)  (0SI19.DAT). 

2.  The  workload  schedule  file  (OSI20.DAT). 

3.  The  MRP  forecast  file  (0SI21.DAT). 
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4.  The  "BOM"  index  (OSI18.DAT). 

5.  Index  to  MRP  forecast. 


The  BOM  file  contains  information  about  items  required 
to  repair  end-items.  The  file  is  a  direct  access  file 
(access  key  is  the  IIC  of  the  end-item)  and  contains  one 
header  record  and  several  data  records  for  each  end- item 
(IIC).  Both  header  and  data  records  have  fixed  lengths. 
The  header  contains  information  about  the  end- item  and 
summary  data  about  the  consumable  items  required  for  its 
repair,  total  cost  of  consumables  for  repair  of  one  IIC 
and  the  total  number  of  the  end- items  that  were  inducted 
in  the  past. 

The  data  record  (one  for  each  consumable  per  end-item) 
contains  the  information  as  described  in  Table  I. 

Figure  6  describes  the  header  layout. 


IIC 

0 

FIC 

NSN 

COG 

Total  Cost 

IIC  Induction  Qty 

1-4 

5 

6-9 

10-22 

23-24 

25-28 

29-32 

Figure  6:  BOM  header-record  layout 


Access  to  the  file  is  based  on  a  pointer  to  the  begin¬ 
ning  of  the  header,  read  from  the  BOM  index  file.  The  header 
is  used,  and  then  (data)  records  are  read  sequentially.  The 
first  character  is  checked  and  if  it  is  other  than  "1"  it 
is  assumed  that  the  end  of  the  IIC  has  been  reached. 


TABLE  I 


The  Data  Record 


Columns 

Description 

Data  Type 

Comments 

1 

Filler 

Char . 

Decimal  Digit  1 

2-14 

NSN 

Char. 

15-16 

COG 

Char . 

17-18 

U/I 

Char . 

19-20 

Planner  § 
Estimator  Code 

Char. 

21-24 

Qty  (total) 

Integer 

Required  for  Qty  in 
header 

25-28 

Unit  price 

Real 

29-32 

#  of  reqn's 

Integer 

Whose  total  Qty  is 
in  21-24 

33-36 

Qty  per  unit* 

Integer 

Max.  Qty  per  1  end 
item 

|  37-38 

U/I  of  Qty  per 
unit* 

Char . 

In  case  it  differs 
from  that  in  17-18 

!  39-40 

Essentiality* 

Char. 

"KE”  or  "NE" 

|  41-44 

Replacement  factor* 

Real 

45-48 

Qty  (Qtr  1) 

Integer 

1 

49-52 

#  of  reqrfs  (Qtr 

1) 

Integer 

1 

i 

53-56 

Qty  (Qtr  2) 

Integer 

57-60 

#  of  reqrfs  (Qtr 

2) 

Integer 

i  61-64 

Qty  (Qtr  3) 

Integer 

65-68 

#  of  reqn's  (Qtr 

3) 

Integer 

69-72 

Qty  (Qtr  4) 

Integer 

73-76 

#  of  reqrfs  (Qtr 

4) 

Integer 

*The  data  is  extracted  from  the  Weapons  Systems  File  (WSF) 
maintained  by  ASO. 
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The  information  for  each  1 1 C  contains  data  from  the  most 
recent  four  quarters.  The  totals  are  kept,  and  an  average 
(total  quantity/quantity  inducted)  is  computed  in  specific 
application  programs. 

The  workload  schedule  file  is  a  sequential  fixed  length 
record  file,  created  especially  for  the  MRP  application. 

It  is  created  by  typing  in  (using  an  interactive  data  entry 
program)  the  workload  schedule  received  from  ASO.  The 
schedule  is  by  FIC  (Family  Identification  Code) ,  as  opposed 
to  the  BOM  file  which  is  by  IIC.  Figure  7  describes  the 
layout  of  a  workload  schedule  record. 


FIC 

NSN  of  FIC 

Workload  Qty 

Standard 

Responsible 

Program 

Scheduled 

Repair  Hours 

Shop 

1  -  4 

5  -  17 

18  -  20 

21  -  26 

27  -  30 

41 

Figure  7:  Workload  schedule  record  layout 

As  seen  from  Figure  7,  the  file  also  contains  information 
that  is  not  necessary  for  MRP- -the  standard  hours  for  repair¬ 
ing  the  scheduled  quantity.  Before  MRP  was  initiated,  there 
was  no  other  file  that  contained  the  production  schedule  and 
repair  standard  hours  and  because  it  was  very  useful  (for 
other  functioners  in  the  NARF)  to  have  them,  they  were  added 
to  the  records. 

The  MRP  forecast  file  contains  the  consumable  NUN 
forecast  for  each  end  item  (IIC).  These,  in  fact,  are  the 
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gross  requirements  before  they  are  summed  to  give  one  quantity 
for  each  NIIN.  This  file  is  used  for  two  main  purposes: 

1.  Provide  data  for  the  material  planners  for  planning 
purposes  (answers  to  queries). 

2.  Record  changes  made  by  the  material  planners  to  the 
gross  requirements  generated  by  MRP.  Those  gross  require¬ 
ments  are  subject  to  inspection,  changes,  deletions  and 
additions  made  by  the  material  planners,  and  this  file  con¬ 
tains  the  last  (best)  version  of  the  requirements  forecast. 

The  file  is  a  direct  access  file  and  consists  of  fixed 
length  records;  each  record  representing  a  consumable  NIIN 
required  for  a  FIC/IIC.  The  data  is  grouped  in  a  hierarchical 
order:  the  highest  level  is  a  FIC,  then  IIC,  and  then  a  con¬ 

sumable  NIIN.  All  data  for  one  FIC  is  co-located  and  sub¬ 
divided  into  IIC's  that  comprise  that  FIC.  Within  an  IIC 
are  all  consumable  NIIN's  required  for  the  repair  of  the  IIC. 

Figure  8  describes  schematically  the  structure  of  the 
file.  Figure  9  describes  the  record  layout  of  the  MRP  fore¬ 
cast  file. 

The  BOM  Index  file  is,  as  its  name  specifies,  the  index 
to  the  bill  of  materials  file,  and  in  addition,  it  also 
contains  the  information  that  is  used  as  the  "translation 
table"  of  the  composition  of  each  FIC  by  IIC's.  This  is 
achieved  by  keeping  the  total  quantity  inducted  by  FIC  and 
the  specific  IIC  quantities  that  comprise  that  quantity. 
Dividing  the  IIC  quantity  by  the  total  (FIC)  quantity  gives 
the  relative  frequency  of  the  IIC  and  allows  for  the 
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Figure  8:  Schematic  Structure  of  MRP  Forecast  File. 


•«-  end  itemf- -  "Consumables'  "  data 


HI 

IIC 

NSN 

COG 

U/I 

Forecast 

Extended  price 

(F8.2) 

MRP  Qty  (16) 

per  consumable 

ESI 

5-8 

9-21 

22-23 

26  -  33 

34  -  39 

40  ^  iU-zJ  49 

NSN 

NSN 

Responsible 

Work 

Program 

Work 

Schedule 

of  IIC 

of  FIC 

Shop 

Standard 

for 

FIC  (13) 

50  -  64 

65  -  77 

78  -  81 

82(fo.  1^7 

88 

89 

91 

Figure  9;  MRP  Forecast  File  Record  Layout. 
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subsequent  translation  of  the  workload  schedule  from  a  FIC 
schedule  to  an  1 1 C  schedule. 

This  index  file  is  used  by  various  application  programs 
to  access  the  BOM  file  and  its  small  size  allows  the  whole 
file  to  be  loaded  into  memory  when  needed. 

The  file  contains  five  different  types  of  records.  A 
Type  1  record  contains  two. fields:  FIC  and  the  starting 
location  of  IIC  location  records  within  this  file.  There 
is  a  single  record  per  FIC  and  each  contains  a  pointer  to 
the  location  of  the  corresponding  IIC's. 

The  Type  1  records  are  delimited  by  a  Type  2  record 
which  simply  contains  the  four  characters  "END*". 

Following  the  Type  2  record  is  a  group  of  Type  3  records 
--one  record  per  FIC,  each  record  containing  "@@@@"  in  the 
first  four  characters  of  the  record  (an  identifier)  and  then 
the  FIC  quantity  of  total  inductions  and  the  FIC  itself. 

This  is  the  data  used  for  the  translation  of  FIC  to  IIC's 
and  could,  in  fact,  have  been  stored  in  the  Type  1  records. 

Type  4  records  contain  the  actual  pointers  to  IIC  loca¬ 
tions  in  the  BOM  file.  Each  record  contains  the  IIC,  IIC 
induction  quantity  (for  translation),  starting  BOM  location 
and  ending  BOM  location  for  this  IIC.  The  Type  4  records 
are  grouped  so  that  all  IIC's  belonging  to  one  FIC  are 
together,  and  the  starting  location  of  this  group  is  being 
pointed  at  by  a  Type  1  record. 

A  Type  5  record  contains  "@@09"  and  "0000"  and  marks 
the  end  of  the  file. 
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The  Index  to  the  MRP  Forecast  file  is  a  regular  index 


file  allowing  access  to  the  master  file  by  different  keys: 
IIC,  FIC  or  NSN. 

C.  SOFTWARE 

The  temporary  MRP  application  consists  of  the  following 
modules : 

1.  File  maintenance 

2.  Queries 

3.  Requirements  generation  module. 

File  maintenance  is  the  set  of  application  and  utility 
programs  that  are  used  to  update  the  BOM  file.  As  described 
in  the  previous  section,  there  is  no  update  of  the  production 
schedule  file. 

The  principle  behind  updating  the  BOM  file  is  to  advance 
the  information  regarding  the  second,  third  and  fourth  quar¬ 
ters  by  one  quarter  forward  (thereby  deleting  the  "oldest" 
quarter),  and  then  insert  the  information  regarding  the  past 
quarter  into  the  fourth  quarter’s  location.  The  file  that 
contains  the  BOM  information  from  the  past  quarter  is  created 
independently  and  is  used  later  as  one  of  the  inputs  to  the 
program  that  creates  the  new  generation  of  the  BOM  file.  The 
same  process  was  utilized  in  creating  the  initial  BOM  file. 
All  that  is  necessary  is  to  stop  after  creating  the  file  with 
the  most  recent  data  (on  the  first  run,  it  is  the  only  data) 
and  use  the  output  as  "the"  BOM  file. 
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The  steps  that  comprise  the  file  maintenance  process 
are  as  follows: 

1.  Create  (by  a  simple  data  entry  program)  a  direct 
access  file  of  all  customer  orders  that  have  been  used 
during  the  last  quarter. 

2.  Using  this  file  as  a  table,  extract  from  the  Demand 
History  File  all  records  that  contain  customer  orders  that 
are  in  the  table.  (Note:  The  customer  order  contains  the 
IIC.) 

3.  Sort  these  records,  which  are  in  fact  consumption 
data,  by  IIC. 

4.  Construct  the  "induction  data"  file  containing  for 
each  IIC  the  total  quantity  inducted  during  the  last  quarter 
Sort  the  output  by  IIC. 

5.  Use  the  induction  data  and  the  consumption  data 
(both  sorted  by  IIC)  to  create  the  one  quarter  BOM  file. 

The  same  information  is  used  to  update  the  FIC  to  IIC  "trans 
lation  table"  that  is  contained  in  the  BOM  file. 

Figure  10  describes  the  file  maintenance  run. 

The  Queries  are  programs  designed  to  assist  the  material 
planners  in  their  work.  There  are  dynamic  queries  in  which 
the  planner  can  change  the  information  in  the  file  he  is 
querying  as  opposed  to  "static"  queries  in  which  the  infor¬ 
mation  is  only  presented. 

The  "static"  queries  include  the  following: - 

1.  Inquire  BOM  by  FIC.  This  inquiry  displays  all  data 
(with  appropriate  headings)  about  the  FIC. 


I'.lt. I  I  III  I  V 


Lu-.  tome  r 
Oi  <lor 
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Figure  10:  BOM  file  maintenance  run. 
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2.  Inquire  BOM  by  IIC. 

3.  Inquire  MRP  forecast  by  the  following  pairs  of 
parameters : 

(a)  $  value/shop 

(b)  $  value/IIC 

(c)  $  value/FIC. 

The  $  value  refers  to  the  value  of  the  consumable  items. 
Such  a  query  will  list  all  consumable  forecasts  for  end 
items/shops  whose  $  value  is  greater  than  the  threshold 
specified  in  the  query.  The  information  about  each  end  item 
is  presented  separately. 

4.  Inquiry  by  a  variable  threshold  of  $  value  of  consum¬ 
ables  value. 

Here  the  planner  specifies  a  value  threshold  and  gets,  in 
return,  all  NSN's  whose  value  is  greater  than  the  threshold 
specified.  This  allows  the  planner  to  concentrate  on  the 
most  expensive  items  first,  and  then  on  the  other  items. 

The  "dynamic"  or  interactive  inquiries  refer  to  the  MRP 
forecast  file  and  are  intended  to  use  the  material  planner’s 
knowledge  in  order  to  get  a  "better"  forecast.  The  planner 
inquires  the  file  by  NSN  (of  consumables)  and  thereby  gets 
sequential  access  to  all  IIC's  that  include  that  consumable. 
After  having  the  information  displayed,  the  planner  can  (by 
using  appropriate  codes)  make  additions,  deletions  or  changes 
in  the  forecast  of  the  requirements  for  that  specific  IIC. 

The  Requirements  Generation  is  the  heart  of  the  appli¬ 
cation  and  concludes  the  whole  process.  This  phase  has  two 
separate  steps: 
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1.  Creation  of  the  MRP  forecast 

2.  Creation  of  the  transactions  for  the  RSS  stock 
replenishment . 

The  MRP  forecast  is  generated  by  computing  an  average 
requirement  for  each  I I C  (total  consumption  during  four 
quarters  divided  by  total  end- item  inductions)  and  then 
multiplying  it  by  the  quantity  of  that  IIC  scheduled  for 
induction  during  the  coming  quarter.  The  IIC  induction 
quantity  is  computed  from  the  FIC  schedule  by  multiplying 
the  FIC  quantity  by  the  relative  frequencies  of  the  IIC's 
composing  the  FIC.  This  forecast  is  used  to  load  the  file 
which  will  be  used  by  the  material  planners. 

After  the  material  planners  have  finished  their  changes, 
the  next  step  is  to  sort  the  requirements  by  NSN  (of  consum¬ 
ables),  sum  them  for  each  NSN  and  write  a  transaction  to  an 
output  file;  this  file  contains  the  NSN  and  the  total 
quantity.  This  quantity  will  have  to  be  in  the  RSS  at  the 
beginning  of  the  quarter  (or  shortly  after  it)  to  ensure 
smooth  operation  of  the  NARF  according  to  the  production 
schedule. 

D.  INPUT,  OUTPUTS  AND  PROCESSING 

The  inputs  to  the  MRP  application  are  mainly  the  outputs 
of  the  UADPS-SP.  These  include  the  demand  history  file  (DHF) 
from  which  the  NARF's  requisitions  are  extracted,  to  be  used 
later  as  consumption  data  for  updating  the  BOM  file,  and  also 
the  MSIR,  from  which  general  information  such  as  nomenclatures, 


units  of  issue,  unit  price  and  auantity-on- hand  (at  the  RSS) 
are  extracted. 

Another  input  is  the  committed  workload  file  (CWF)  which 
contains  induction  quantities.  This  file  is  maintained  by 
NARDAC  for  the  independent  production  control  application. 

The  workload  schedule  file  that  was  described  in  the  data¬ 
base  section  is,  of  course,  another  important  input  to  the 
system. 

The  last  input  is  the  set  of  valid  customer  orders  (job 
numbers)  which  are  entered  through  an  interactive  data-entry 
program  and  are  used  as  a  table  for  extracting  relevant 
records  from  the  DHF. 

All  inputs  described  above,  except  the  MSIR,  are  origin¬ 
ated  at  the  NARF,  although  part  of  them  (DHF,  CWF)  finally 
arrive  at  the  MRP  application  as  external  inputs.  This  is 
an  important  factor  because  it  leaves  very  little  control 
(frequency,  data  integrity)  that  can  be  imposed  by  the  MRP 
application. 

The  outputs  from  the  MRP  application  were  also  described 
earlier.  They  include  essentially  the  transactions  for  level 
setting  of  RSS  stock,  answers  to  queries  by  the  material 
planners  and  various  reports  which  are  generated  during  the 
process  of  file  maintenance  and  requirements  generation.  In 
a  well  developed  system,  these  reports  would  have  been  outputs 
of  other  applications,  but  since  these  do  not  exist  at  the 
NARF,  this  was  an  opportunity  to  produce  these  products. 
Examples  of  these  products  are  a  list  of  customer  orders 


(instead  of  a  production  schedule),  summary  induction  infor¬ 
mation  by  IIC,  and  BOM  listings  for  general  use  by  material 
planners  (as  back-up  to  inquiries). 

The  MRP  application  involves  two  modes  of  processing. 

The  first  is  the  process  of  file  maintenance  and  require¬ 
ments  generation  which  is  run  once  per  quarter.  The  other 
is  the  inquiry  system,  in  which  files  and  programs  are  loaded 
permanently  and  used  by  the  material  planners. 

The  file  maintenance  involves  a  sequence  of  events  that 
determines  the  schedule  of  the  whole  process.  The  first 
constraint  is  that  the  BOM  cannot  be  updated  as  long  as 
customer  orders  are  still  active  because  the  consumption  is 
not  complete  yet.  Customer  orders  are  closed  at  the  end  of 
the  second  month  of  the  quarter  following  the  quarter  for 
which  they  were  opened;  this  then  is  the  earliest  time  for 
the  beginning  of  the  process. 

A  second  constraint  is  imposed  by  the  determination  of 
the  production  schedule.  This  is  done  in  a  conference  that 
takes  place  during  the  first  week  of  the  third  month  of  each 
quarter,  and  during  the  conference  the  schedule  for  the 
coming  quarter  is  determined  and  a  tentative  schedule  is 
prepared  for  the  following  quarter. 

Consequently,  the  processing  goes  as  follows:  The  old 
BOM  and  the  tentative  production  schedule  are  used  to  pre¬ 
pare  the  background  information  for  the  conference  (identify 
critical  items  required  to  carry  out  the  schedule) .  Then, 
during  the  first  week  of  the  third  month,  the  file  maintenance 
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run  is  performed  making  the  BOM  ready  for  generation  of  the 
gross  requirements.  The  requirements  generation  program  is 
run  in  the  second  week  of  the  third  month  using  the  final 
production  schedule  that  was  determined  in  the  conference. 

The  MRP  forecast  is  then  loaded  for  analysis  by  the  material 
planners  who  have  another  week  to  make  their  changes  in  the 
material  forecast.  At  the  end  of  the  third  week  the  final 
run  is  made  and  the  transactions  are  generated  and  submitted 
to  NSC  Oakland.  This  leaves  at  least  seven  days  for  NSC 
Oakland  to  process  the  transactions  and  to  position  the 
materials  in  the  RSS. 

E.  EVALUATION  OF  THE  TEMPORARY  MRP  SYSTEM 

A  review  of  the  temporary  MRP  application  reveals  a  number 
of  problems.  The  first  problem  relates  to  the  production 
schedule.  Implementation  of  MRP  requires  the  existence  of 
such  a  schedule.  The  NARF  does  not  have  an  automated  produc¬ 
tion  schedule,  and  the  file  that  is  used  here  is  created 
especially  for  the  MRP  run.  Consequently,  the  file  is  used 
only  for  MRP  and  lacks  feedback  and  updates  as  the  schedule 
is  carried  out.  Therefore,  the  possibility  of  updating  the 
material  requirements  during  the  quarter  does  not  exist. 

The  file  maintenance  software  also  involves  some  problems. 
The  software  was  designed  with  simplicity  as  a  goal,  thus 
leaving  some  areas  uncovered.  One  of  these  is  the  update  of 
the  BOM  file  as  new  jobs  appear.  Since  the  only  basis  for 
updating  the  BOM  file  is  actual  jobs  that  have  been  completed 
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in  the  past  quarter,  there  is  no  way  to  enter  information  or 
estimates  about  jobs  that  are  scheduled  for  the  first  time. 
This  means  that  the  system  will  not  be  able  to  forecast  re¬ 
quirements  for  the  whole  production  schedule,  and  there  will 
always  be  some  customer  orders  that  will  not  have  materials 
prepared.  This  problem  is  partially  solved  by  allowing 
material  planners  to  change  forecasts,  but  they  do  not  have 
the  possibility  of  inserting  a  whole  new  item. 

Validity  checks  on  input  are  another  problem  that  is 
treated  only  partially.  Although  most  of  the  inputs  come 
from  other  systems,  there  still  should  be  some  checks, 
especially  on  the  reasonableness  of  material  consumption. 

An  analysis  of  the  NARF's  requisitions  during  the  period  of 
April  1978  until  March  1980  revealed  many  requisitions  for 
very  large  quantities,  presumably  resulting  from  combined 
requisitions  for  more  than  one  customer  order,  but  reported 
on  only  one  order.  If  such  quantities  are  not  extracted 
(by  some  kind  of  inspection),  they  may  ruin  the  averages  in 
the  BOM  file  and  consequently  the  whole  forecast. 

The  way  the  system  was  developed  may  introduce  a  prob¬ 
lem  after  the  system  becomes  operational.  The  system  was 
designed  and  implemented  by  a  project  officer  and  two  pro¬ 
grammers  that  were  especially  hired  for  this  mission.  The 
involvement  of  other  people,  and  especially  users,  in  the 
NARF's  500  Department  was  minimal  and  this  means  that  a 
special  effort  will  be  required  to  train  the  users,  acquaint 
them  with  the  new  tool,  and  make  them  efficiently  utilize 


the  system.  The  lack  of  good  documentation  (because  the 
software  was  written  by  people  that  were  hired  for  a  very 
short  period  of  time)  will  make  that  job  very  difficult. 


V.  THE  PROPOSED  MRP  SYSTEM 


The  proposed  MRP  system  is  designed  to  meet  the  same 
objectives  as  the  temporary  system,  i.e.,  forecast  of  NARF's 
material  requirements,  maintain  and  update  the  required  data¬ 
base,  and  provide  the  appropriate  interface  to  the  supply- 
support  system.  However,  the  introduction  of  ASKARS,  as  well 
as  the  problems  that  have  been  identifi.  x.r  the  temporary 
system,  require  and  provide  the  opportunity  to  introduce 
some  improvements.  And  that  is  what  the  proposed  system  is 
intended  to  do. 

The  intent  of  this  chapter  is  to  provide  a  functional 
design  of  the  proposed  system.  It  should  serve  as  the  basis 
for  detailed  design  and  implementation  by  NARF  Alameda  people 
after  ASKARS  becomes  operational. 

The  implementation  of  ASKARS  raises  the  following  factors, 
which  will  become  important  to  the  design: 

1.  New  ADP  equipment  will  be  installed.  In  addition, 
there  will  be  new  software  and  application  programs;  this 
requires  compatibility  between  the  system  on  which  MRP  will 
be  run  and  ASKARS.  A  logical  solution  is  to  run  MRP  on  the 
ASKARS  ADP  equipment. 

2.  The  available  time  for  design  and  implementation  of 
the  proposed  system  is  long  enough  to  prevent  short-cuts 
because  of  time  pressures. 
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3.  The  implementation  of  ASKARS  requires  professional 
ADP  people. 

4.  ASKARS'  software,  and  especially  the  order  processing 
module  [22:  Enclosure  (1),  Section  5],  has  many  similarities 
to  MRP.  The  use  of  the  same  or  a  slightly  changed  approach 
in  the  design  of  the  MRP  system  will  increase  the  understand¬ 
ing  of  the  MRP  system  and  facilitate  its  implementation  and 
maintenance. 

A  major  component  of  the  proposed  system  is  the  algorithm 
for  generation  of  the  gross  requirements.  The  fact  that  NARF 
Alameda  performs  mainly  maintenance  instead  of  production 
results  in  an  uncertainty  about  the  BOM  information.  This 
has  been  treated  only  in  a  minor  way  in  the  temporary  system. 
Therefore,  a  considerable  effort  is  devoted  here  to  develop 
a  better  and  more  accurate  algorithm  to  handle  this  uncer¬ 
tainty. 

Another  important  area  that  this  system  considers  is  the 
production  schedule  and  the  human  resources  (professions  and 
standard  hours)  that  are  required  to  carry  out  the  schedule. 
Since  a  production  schedule  file  is  not  in  existence  at 
present,  a  simple  application  is  proposed  below.  It  will 
satisfy  the  MRP  requirements  as  well  as  the  basic  needs  of 
the  production  and  control  people. 

Production  planning  and  control  was  also  a  major  factor 
in  the  design  of  the  BOM  data  structure.  It  provides  the 
basis  for  inclusion  of  other  resources  in  the  BOM  file. 
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This  may  contribute  further  to  a  better  and  accomplishable 
production  schedule.  This  will  not  be  developed  here  in 
detail,  but  will  be  outlined  for  further  development  in  the 
future. 

A.  PRM-MRP :  PROBABILISTIC  REPLACEMENT  MODEL  FOR  MRP 

This  section  is  devoted  to  the  development  of  the  proposed 
model  for  material  requirements  planning  in  a  maintenance 
oriented  facility. 

1 .  The  Demand  Distribution 

The  demand  for  an  item  in  a  maintenance  oriented 
environment  is  determined  by  the  following  three  factors :- 

a.  The  Production  Schedule 

It  determines  the  end  items  that  will  be  reworked 
and  thereby  determines  the  set  of  consumable  items  that  are 
candidates  for  consumption.  The  candidates  are  the  compon¬ 
ents  that  make  up  the  scheduled  end-items. 

b.  The  Replacement  Factors 

The  replacement  factor  of  a  consumable  item 
that  comprises  a  specific  end-item  corresponds  to  the  pro¬ 
portion  of  the  installed  quantity  of  that  consumable  item 
in  one  end- item  that  is  expected  to  be  replaced/consumed 
in  the  course  of  reworking  the  end- item.  The  replacement 
factor,  P,  takes  on  values  such  that  0  ^  P  £  1  where  P=1 
represents  consumables  that  are  always  replaced  during  repair 
of  the  end- item  and  P  =  0  represents  components  that  are  never 
replaced.  The  replacement  factor  is  affected  by  maintenance 


policies,  experience  of  the  people  that  do  the  maintenance, 
and  by  the  nature  of  the  item  and  the  environment  in  which 
it  is  used. 


c.  The  Demand  Distribution  for  the  Item 
Being  Replaced 

Let  n^,  n^,  •  •  •  »  nm  be  the  installed  quantities 
of  a  consumable  item  in  m  different  end  items  IIC^,  IIC^, 

. . . ,  1 1 Cm ,  respectively.  Let  ,  P  .  .  .  ,  Pm  be  the  corre¬ 
sponding  replacement  factors  of  that  consumable  item  and  let 
Qlt  be  the  scheduled  quantities  per  quarter  for 

the  end  items.  Let  be  a  random  variable  representing  the 
demand  for  the  consumable  item  during  the  quarter  for  the 
scheduled  repair  of  1 1 C ^ .  Then,  X^  has  a  Binomial  distribu¬ 
tion,  namely 

n.Q.  X.  n.Q.  -  X- 

b(Xi;niQi,Pi)  "  (  J  )PA  U  "  P^)  1  ,  i «  1, 2  ,  . .  .  ,m 

The  mean  of  the  distribution  is  n^Q^P^  and  the  variance  is 

niQiPi C1  ‘  V*  [27:28,69]. 

Each  X^  is  an  independent  random  variable  because 
the  demand  for  an  item  by  an  IIC  is  independent  of  the  demand 
for  that  item  by  another  IIC. 

Consider  now  the  total  demand  for  an  item  during 
a  quarter.  Let  it  be  the  random  variable  X.  It  follows 
that 

X  =  X.  +  X7  +  . . .  +  X  . 

12  m 

The  mean  of  X  Cor  expected  value  of  X)  is 


L 
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Similarly,  since  X^,X,,...,Xm  are  independent  variables,  the 
variance  of  X,  VarCX),is 


Var(X)  =  n1Q1P1(l-P1)*n2Q2P2(l-P2)*....nmQniPm(l-Pm) 


m 


The  probability  distribution  of  X  can  be  approxi¬ 
mated  (with  continuity  correction)  by  the  Normal  distribution. 

2 .  The  Basic  Model 

Planning  Horizon- -Repair  schedules  are  developed  on  a  quar¬ 
terly  basis  at  the  NARF.  Additionally,  the  inventories  of 
consumable  repair  parts  are  funded  either  from  the  Navy  Stock 
Fund  (NSF)  if  provided  and  managed  by  a  NSC  or  by  the  Navy 
Industrial  Fund  (NIF)  if  purchased  and  managed  by  the  NARF. 
Both  funds  serve  as  revolving  funds  which  provide  a  fixed 
amount  of  money  for  a  given  quarter  to  buy  inventories. 
Customers  are  billed  for  items  used  and  submit  payments  to 
these  funds.  The  money  collected  is  returned  to  the  NSC  or 
the  NARF  at  the  beginning  of  the  next  quarter.  Adjustments 
in  the  amount  of  money  in  either  fund  is  made  quarterly  or 
less  frequently  depending  on  the  variation  in  the  production 
schedule . 

Because  of  the  repair  schedule  and  the  nature  of  the 
NSF  and  the  NIF,  demand  for  repair  parts  appears  to  be  inde¬ 
pendent  from  one  quarter  to  the  next.  Therefore,  the  model 


to  be  presented  below  will  have  a  planning  horizon  of  one 
quarter  in  length  and  will  be  what  is  known  in  inventory 
theory  asa"single  period”  model  [14:  Chapter  6]. 

Ob  j  ective- -  In  providing  an  inventory  of  repair  parts  the 
logical  objective  is  to  strive  for  a  maximum  availability  of 
each  item.  If  it  is  known  that  an  item  is  replaced  100%  of 
the  time  during  overhaul  of  an  end  item,  then  it  is  logical 
to  stock  for  that  10 0%  level.  The  MRP  approach  will  determine 
the  total  quantity  of  such  an  item  easily. 

If,  however,  an  item  is  replaced  less  than  100%  of  the 
time,  then  stocking  that  item  to  the  100%  level  is  going  to  be 
wasteful  unless  future  quarters'  production  schedules  are  able 
to  absorb  any  surplus.  A  surplus  at  the  end  of  a  quarter  in 
absence  of  knowledge  of  future  schedules  results  in  NSF  or  NIF 
money  being  tied  up  which  could  have  been  used  to  buy  more  of 
some  other  item  either  in  the  upcoming  or  in  the  past  quarter. 

Thus,  a  balance  needs  to  be  sought  between  the  chance 
of  a  surplus  and  the  chance  of  a  deficit  for  the  items  not 
replaced  100%  of  the  time  such  that  the  remaining  funds  in  the 
NSF  or  NIF  (after  the  "100%  items"  are  purchased)  are  used 
efficiently. 

Objective  Function- -The  balance  being  sought  above  will  be 
determined  by  developing  an  objective  function  which  describes 
the  expected  costs  for  all  the  items  not  replaced  at  the  100% 
level  as  a  function  of  the  amount  of  each  item  to  be  placed  in 
the  RSS  or  NIF  stores  at  the  beginning  of  the  quarter.  The 
following  costs  are  assumed  to  be  appropriate  for  this  function. 
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a.  Processing  Costs 


c.  Penalty  Costs 

Two  forms  of  penalty  costs  should  be  considered. 

The  first  is  a  shortage  cost  for  being  out  of  stock  at  some 
time  before  the  end  of  the  quarter;  the  second  is  a  surplus 
cost  for  having  undemanded  units  of  an  item  still  in  stock  at 
the  end  of  a  quarter. 

In  the  case  of  a  shortage,  a  unit  must  be  obtained 
from  outside  the  store.  In  the  case  of  the  RSS,  this  unit 
might  be  available  at  the  NSC  or  it  might  have  to  be  obtained 
somewhere  else  in  the  supply  system.  In  the  case  of  a  NIF 
store  it  would  probably  have  to  be  obtained  from  the  appropriate 
DLA  or  GSA  source.  Concentrating  on  the  RSS  from  now  on,  we 
assume  a  cost  of  rr^  per  unit  requisitioned  from  the  NSC  and  a 
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cost  of  7T 2  per  unit  requisitioned  from  outside  the  NSC. 

These  costs  should  reflect  the  time  delays  resulting  from 
having  to  go  outside  the  RSS.  It  is  reasonable  to  assume 
that  rr j  <<  tt 2 - 

If  demand  X  for  an  item  exceeds  y,  the  amount  in 
the  RSS,  then  the  shortage  cost  will  be: 

it 2.  [X-y]  , 

if  X  is  not  so  large  that  the  stock  w  at  the  NSC  is  also 
exhausted  (that  is,  X  £  y  +  w).  If  X  is  so  large  that  we 
must  go  to  the  outside,  then  the  cost  will  be: 

tt1w  +  tt2  [X  -  y  -  w]  . 

In  the  case  of  a  surplus,  the  unit  cost  for  having 
a  surplus  is  assumed  to  be  kC  where  C  is  the  unit  purchase 
cost  and  k  is  a  factor  which  may  be  greater  than  1.0.  The 
cost  of  a  quarter's  surplus  can  be  then  written  as 

kC[y  -  X]  , 

and  applies  only  if  X  <  y. 

d.  Expected  Total  Costs 

If  we  let  p(x)  represent  the  binomial  probability 
that  X  units  are  demanded  during  the  quarter  for  a  given  item, 
the  expected  total  cost  for  the  quarter  can  be  written  as: 

EC(y)  «  [C  +  C.]y  +  z  kC[y  -  XjpCx) 
p  n  X=o 

y+w  ni 

+  X-y+l*1^  "  y3p(x) 

+  J  ("iw  +  Ix  *  y  -  w]  }p(x) 

X*y+w+l 
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If  the  demand  is  sufficiently  large  that  demand  can  be 
assumed  to  be  Normal  then 

y 

EC(y)  =  [C  +  C,]y  +  /kC[y  -  X]f(x)dx 
f  o 

y+w 

+  /  tt  [X  -  y]  f  (x) dx  (2) 

y 

+  f°°  +  7T  2  [  X  -  y  -  w]}f(x)dx, 

y+w 

where  f(x)  denotes  the  density  function  for  the  associated 
Normal  distribution. 

Optimal  Order  Quantity- -The  basic  model  seeks  to  determine  a 
value  for  y  _>  0  which  minimizes  EC(y)  in  either  the  discrete 
form  of  equation  (1)  or  the  continuous  form  of  equation  (2). 

The  calculus  can  be  applied  to  equation  (2)  to  get 
optimal  y.  Taking  the  first  derivative  of  EC(y)  with  respect 
to  y  and  setting  it  equal  to  zero  results  in 


F(y) 


cp  *  ch  *  kc  '  tff2  ~  ^jJ^Cy + w) 


it  j  +  k  C 


(3) 


where 


and 


F(y)  =  fy  f  (x)dx 


F(y  +  w)  =  f  f£x)dx. 


In  the  discrete  case  we  want  the  largest  value  of  y  for  which 

(4) 


*  CD  +  Ch  +  kC  '  1*2  *  lTi]p(y  +  w) 

F(y)  >  -2-  n  z  i 


tt  ^  +  kC 
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where 


F Cy)  =  2  p(x) 

X=y 

and 


P(y  +  w)  =  I  p (x) 
X-y+w 


This  results  from  the  analysis  of  finite  differences  in  which 
we  seek  the  largest  value  of  y  for  which 


EC  (y)  -  EC(y  -  1)  <  0. 


In  the  event  that  the  NSC  has  a  large  stock  outside 
the  RSS  we  can  assume  w  -*■  »  and  equations  (3)  and  (4)  reduce 
to 


F(y) 


+  C^  +  kC 
it  2  +  kC 


(5) 


P(y) 


> 


C  +  Ci  +  kC 
P  h 

+  kC 


(6) 


3 .  Extensions  of  the  Basic  Model 

The  basic  model  described  above  did  not  consider 
situations  where  two  or  more  end  items  are  demanding  units  of 
the  same  repair  part  and  where  a  budget  constraint  limits  the 
amount  of  units  which  can  be  purchased  for  each  of  two  or  more 
repair  parts. 

Two  End- Items  Demanding  the  Same  Repair  Part- -To  study  this 
case,  let  X^^  and  X2  be  the  units  of  a  certain  repair  part 
demanded  by  end  items  Nos.  1  and  2,  respectively.  The  total 
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demand  X  for  the  repair  part  is  then  the  sum  of  and  X7; 

1 

namely , 

X  -  Xx  +  X2  . 

The  surplus  cost  term  of  the  expected  cost  for  a 
quarter  is  the  same  form  as  above,  namely, 

Z  kC[y  -  X] p (x) 

X=o 

or 

y 

/  kC [y  -  X] f (x)dx  ; 
o 

except  that  now  p(x)  and  f (x)  are  the  probability  and  density 
function  associated  with  a  total  demand  of  X.  Since  X  is  the 
sum  of  X^  and  X2  and  since  X^  and  X2  are  independent  random 
variables  we  have  a  density  function  for  X  which  is  approx¬ 
imately  Normal  as  discussed  earlier. 

The  shortage  cost  term  is  more  difficult  to  develop. 
Let  us  assume  that  a  quarter  has  a  length  of  T  time  units 
and  that  the  supply  y  of  an  item  is  exhausted  at  t  time  units 
after  the  start  of  the  quarter.  It  follows  that  if  t  <  T 
then  a  shortage  will  occur  before  the  quarter  ends.  Let  us 
also  assume  that  the  two  end  items  consume  at  rates  r^  and 
r2  where 


From  knowledge  of  r^  and  r2  we  can  determine  t  since 
Irl  +  r2]t  =  y  . 
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Thus  , 
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(7) 


where 


EC(y)  »  [Cp>Ch]y  ♦  fQ  kC[y  -  X]f(x)dx 


+  fy  [X  -  y]f  (x)dx 


_  =  ^ll^l  *  7T12u2 

1  U1  +  y2 


The  optimal  value  of  y  can  be  determined  from  equation  (5) 
if  is  that  given  by  equation  (8)  and  F(y)  uses  the  distri¬ 
bution  of  the  random  variable  X  where  X  =  X^  +  X2. 

More  than  Two  End- 1  terns  Demanding  the  Same  Repair  Part 

Equations  (7)  and  (5)  are  still  applicable  when  we  have 
n  end- items  if  we  use 


X  =  X.  +  X,  +  ...  +  X„ 
12  n 


_  _  Wl  +  *12^2  +  +  Vn 

1 

yl  +  y2  *  +  yn 


The  model,  and  the  problems  associated  with  providing 
the  data  it  requires,  are  further  discussed  in  Appendix  E. 
However,  the  discussion  in  the  following  sections  assumes 
that  the  necessary  data  will  be  available. 
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B.  SUPPORTING  INFORMATION 


The  basic  principles  of  an  MRP  system  and  an  example  of 
a  system  that  satisfies  some  of  the  NARF ' s  needs  has  been 
described  in  previous  chapters.  Therefore,  the  material 
presented  hereafter  will  not  repeat  all  the  details  and  will 
assume  that  they  are  clear. 

1 .  Outputs,  Inputs  and  Data-Base 

The  outputs  of  the  proposed  MRP  system  are  basically 
the  same  as  those  of  the  temporary  system.  The  main  differ¬ 
ence  should  be  in  the  accuracy  of  the  forecast  that  the  system 
generates . 

The  system  will  produce  the  following  outputs: 

1.  Material  requirements  forecast. 

2.  Answers  to  queries  about  the  forecast  and  the  BOM 
file . 

3.  Transactions  for  RSS  level  setting. 

4.  Transactions  for  updating  the  ASKARS  order  processing 
module . 

The  additional  transactions  generated  by  the  MRP 
system  are  designed  to  provide  the  input  to  ASKARS  that  will 
allow  using  its  existing  software  for  follow-up  on  the  trans¬ 
actions  submitted  to  NSCO  from  submission  until  the  material 
is  received  and  placed  in  the  appropriate  bins  in  ASKARS. 

The  types  of  inputs  to  the  system  and  the  data-base 
are  the  same  as  in  the  temporary  system.  The  structure  of 
the  files  and  the  fields  in  the  records  are  different  but 
basically  the  same  kind  of  inputs  are  used  to  maintain 
similar  files.  However,  there  are  two  differences: 


a.  The  input  for  maintaining  a  production  schedule 
will  be  more  involved  but  will  upgrade  the  quality  of  the 
data-base.  This  subject  is  covered  in  detail  in  a  special 
section  on  the  production  control  subsystem. 

b.  The  material  requirements  forecast,  which  is  an 
output  of  the  system,  will  also  be  an  input  to  another  pro¬ 
gram  that  will  use  the  same  information  to  generate  the 
order  processing  transactions  for  ASKARS. 

2 .  Functions 

The  MRP  system  will  perform  the  following  functions: 

a.  Input  edit. 

b.  Query. 

c.  Report  generation. 

d.  File  maintenance. 

e.  RSS  level  setting. 

f.  Generation  of  information  for  requisition  follow-up. 

g.  Analysis  to  identify  exceptions  (in  material  usage). 

3.  Algorithms 

Four  algorithms  are  needed  for  MRP. 

a.  Extract  data  from  given  files  according  to  required 
fie Ids /sequences. 

b.  Sort  files  according  to  required  fields/sequence. 

c.  Translate  FIC  to  IIC's  and  vice  versa. 

d.  Generate  requirements  for  given  quantities  of  IIC's. 

The  first  two  algorithms  are  in  fact  utility  programs 
that  are  usually  provided  with  the  operating  system  and  can 
be  used  on  any  file.  On  the  other  hand,  the  translation 
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algorithm  and  the  algorithm  for  generating  the  material 
requirements  are  specific  to  this  application  and  will  be 
developed  later  on. 

4 .  Environment 

The  environment  for  running  the  MRP  system  includes 
both  time-sharing  and  batch  processing.  Time  sharing  is 
required  for  the  queries  whereas  all  other  runs  are  in  batch. 
ASKARS'  operating  system  requires  and  permits  both  environ¬ 
ments  [ 22 ]  . 

5 .  Information  Network 

Running  the  MRP  system  involves  the  500  Department 
at  NARF  Alameda  which  is  responsible  for  the  application  and 
some  external  activities  that  provide  inputs  to  the  system 
or  use  the  system's  output.  Among  those  are  NSC  Oakland, 
the  production  and  supply  departments  at  the  NARF,  the 
ASKARS  system  and  ASO.  Figure  11  depicts  the  information 
network  for  the  proposed  MRP  system. 

C.  MATERIAL  REQUIREMENTS  ALGORITHM 

The  algorithm  for  determining  material  requirements  for 
repair  of  end- items  is  the  heart  of  the  system  and  there¬ 
fore  it  will  be  described  in  full. 

The  algorithm  is  expected  to  be  called  in  two  cases 

1.  Queries. 

2.  Generation  of  the  quarterly  material  requirements 
forecast. 

The  two  instances  differ  in  that  a  query  will  usually 
involve  a  single  (or  a  small  number  of)  end  items  whereas 
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Figure  11:  Proposed  MRP  System  --  Information  Network.  (Frequency 
of  runs  and  volumes  of  transactions  are  given  in 
Appendix  B.) 
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the  second  case  involves  the  whole  production  schedule. 

This  implies  that  the  algorithm  should  provide  a  means  for 
calling  it  for  more  than  one  end-item. 

Another  requirement  is  to  allow  the  user  (especially  in 
queries)  to  provide  either  a  FIC  or  an  I I C  and  have  the 
program  do  all  additional  work  to  get  the  end  result. 

A  calling  sequence  that  will  meet  the  requirements  is 
CALL  MRP (ID,T,Q,S,E)  where:- 

ID  =  End-item  identification  code  (input  parameter). 

T  =  Type  of  identification  code  (input  parameter). 

a.  "1"  for  IIC. 

b.  "2"  for  FIC. 

Q  *  End-item  scheduled  quantity  (input  parameter). 

S  =  Sequence  code  (input  parameter). 

a.  "1"  to  specify  first  call. 

b.  "2"  to  specify  that  the  subroutine  was 
called  previously  in  this  computation. 

c.  "3"  to  specify  that  there  are  no  more  end-items. 

E  =  Error  code  (output  parameter). 

Subroutine  MRP  will  be  called  from  other  programs.  The 
parameters  will  be  either  supplied  explicitly  by  the  user 
(ID,T,Q)  or  implied  (S)  by  events  (first  item,  EOF  or  special 
ID).  Of  special  importance  is  the  sequence  code  that  deter¬ 
mines  what  modules  will  be  executed.  This  code  is  set  to 
"1"  by  the  calling  program  for  the  first  end-item.  Subse¬ 
quent  calls  will  have  the  sequence  code  "2"  and  when  there 
are  no  more  items  the  calling  program  will  issue  a  terminating 
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call  (  CALL  MRP  (9999 , 1 , 0 , 5 , 0)  )  that  will  tell  the  algorithm 
to  proceed  to  the  next  phase  of  summing  up  requirements. 

The  MRP  algorithm  includes  two  phases  of  processing  as 
shown  in  the  block  diagram  in  Figure  12.  In  the  first  phase 
the  end-items  are  specified  by  the  caller  and  used  as  access 
keys  to  the  BOM  (directly  when  end-item  is  an  1 1 C  or  indirectly 
via  the  FIC  to  I I C  translation  table  when  the  ID  is  for  a  FIC. 
Then,  the  BOM  information  and  Q  are  utilized  to  compute  "raw" 
material  requirements  and  to  write  records  (one  per  NSN)  to 
the  raw  materials  file  (an  intermediate  file).  This  phase 
ends  when  the  subroutine  accepts  the  terminating  call  (S =  3) . 
This  causes  execution  of  Phase  II  which  begins  with  sorting 
of  the  raw  requirements  by  NSN,  computing  total  requirements 
per  consumable,  and  writing  the  result  to  the  final  output. 

Customer  orders  that  are  in  the  production  schedule  and 
have  been  started  previously  require  special  processing  during 
RSS  level  setting.  It  is  not  of  concern  in  queries  since  the 
material  planner  only  wants  to  know  the  material  requirements 
for  a  new  job. 

Semi-finished  jobs  are  processed  by  the  Regenerative  MRP 
model.  The  requirements  for  the  rest  of  an  unfinished  job 
are  determined  by  subtracting  the  actual  consumption  thus 
far  on  such  a  job  from  the  material  requirements  for  the 
whole  job.  The  production  schedule  that  is  the  input  for 
RSS  level  setting  will  include  uncompleted  customer  orders. 
However,  the  actual  consumption  on  the  customer  order  from 
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the  previous  quarter  will  be  extracted  from  the  DHF  and  RSF 
(by  customer  order)  and  this  temporary  file  (Expended  Mater¬ 
ials  file)  will  be  another  input  to  Phase  II  of  the  subroutine. 
This  means  that  the  Raw  Material  Requirements  file  and  the 
Expended  Materials  file  will  be  read  in  parallel  (matching) 
and  the  gross  requirements  for  -a  consumable  NSN  will  be 
derived  by  taking  the  difference  between  the  total  forecast 
quantity  for  that  item  (computed  by  the  PRM-MRP  computation) 
from  the  Raw  Material  Requirements  file  and  the  total  quantity 
for  that  item  in  the  Expended  Materials  file.  Figure  13 
shows  the  record  layout  for  the  Raw  Material  Requirements 
file.  This  file  also  contains  the  necessary  information  for 
computing  the  probability  distribution  function  for  the  total 
requirement. 

The  final  output  from  the  MRP  subroutine  will  be  later 
formatted  in  the  calling  program  (or  by  a  different  program) 
to  either  write  the  level  setting  transactions  or  to  display 
them  on  the  terminal. 

Subroutine  MRP  involves  some  error  checking  and  parameter 
validations.  A  list  of  the  errors  the  program  will  look  for 
is  given  in  Table  II.  The  successful  completion  or  the 
detection  of  an  error  will  be  reflected  in  the  E  parameter 
of  the  subroutine  which,  in  fact,  is  a  return  code.  A 
return  code  which  is  other  than  ”0"  will  cause  the  calling 
program  to  display  an  appropriate  error  message  and,  in  the 
case  of  material  forecast  generation  for  RSS  level  setting, 
the  exclusion  of  that  end- item  from  the  forecast. 


TABLE  II 


Errors  Returned  by  Subroutine  MRP 


Error  Return 
Code* 

Corresponding 

Parameter 

Explanation 

00 

Successful  call 

11 

ID 

IIC/FIC  does  not  exist 

21 

T 

Invalid  type  (other  than 

1  or  2) 

31 

Q 

Invalid  quantity  (must  be 
an  integer) 

41 

S 

Invalid  sequence  code 
(other  than  1,  2  or  3) 

42 

S 

First  call  before  a  previous 
computation  was  completed 

43 

S 

S  =  2  without  a  previous  call 
with  S  =  1 

44 

S 

S  =  3  and  other  parameters 
not  as  required 

49 

s 

Warning.  S  =  3  without 

S  *  1  or  S  =  2 . 

*  The  return  call  is  an  output  parameter  and  is  checked  by 
the  calling  program. 
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Figure  13:  Raw  Material  Requirement  Record  Layout. 

Figure  14  shows  the  detailed  flow-chart  of  the  subroutine. 

The  subroutine  will  require  approximately  150  lines  of 
high- level- language  code.  When  executed,  it  requires  on-line 
storage  for  the  BOM  file,  the  Inventory  Status  file  (MSIR 
Extract),  the  FIC  to  IIC  translation  table,  and  the  Raw  Material 
Requirements  file.  In  addition,  memory  is  required  for  input 
and  output  buffers  and  for  the  table  created  by  the  subroutine 
for  issuing  calls  by  IIC  when  the  original  call  is  by  FIC. 

These  resource  requirements  add  up  to  approximately  50K  Bytes 
of  memory  and  100MB  of  on-line  storage. 

D.  THE  PRODUCTION  CONTROL  SUBSYSTEM 

The  existence  of  a  production  schedule  is  one  of  the  MRP 
prerequisites.  Since  the  present  production  and  control 
system  at  NARF  Alameda  does  not  provide  satisfactory  and  up 
to  date  information,  there  is  a  need  to  develop  the  appro¬ 
priate  software  and  maintain  the  required  data  base  that 
will  satisfy  the  proposed  MRP  application. 

The  Production  Control  Subsystem  (PCS)  is  designed  to 
produce  the  following  outputs: 

1.  Production  schedule  listings. 
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Lgure  14:  (continued) 
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2.  Answers  to  queries  about  the  status  of  customer 
orders . 

3.  Input  edit  reports. 

4.  Progress  and  exception  reports. 

Production  schedule  listings  will  be  produced  in  two 
different  sequences.  The  first  sequence  will  list  all 
customer  orders  that  exist  in  the  data-base.  This  report 
will  be  used  by  the  production  planners  in  the  500  Department 
and  the  production  department  head  (900  Department).  The 
report  in  the  other  sequence  will  be  used  by  branch  heads  in 
the  900  Department  and  each  report  will  contain  only  the 
customer  orders  with  which  the  shop  is  involved.  Both 
reports  will  contain  the  same  information  but  in  different 
sequences  of  customer  orders. 

The  queries  will  provide  essentially  the  same  information 
as  the  production  schedule  listings.  However,  the  query  will 
refer  to  one  customer  order  only  and  will  display  the  rele¬ 
vant  up  to  date  information.  The  queries  will  be  by  customer 
order,  by  FIC  or  by  IIC. 

The  intent  of  the  input  edit  report  is  to  give  the  status 
of  the  transactions  that  were  submitted  to  the  system.  Trans¬ 
actions  that  contain  errors  will  show  up  in  the  report  with 
appropriate  error  codes  specifying  what  the  error  was;  for 
example,  invalid  record  type,  invalid  dates  or  missing  data 
items . 

The  progress  and  exception  reports  will  resemble  the 
production  schedule  listings  in  format.  The  difference  will 
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be  in  the  information  printed  in  the  reports.  This  informa¬ 
tion  includes  standard  hours  for  completion  of  the  whole  job, 
number  of  hours  expended  in  the  job  since  the  previous  edi¬ 
tion,  and  exception  messages  for  those  customer  orders  in 
which  progress  was  not  satisfactory. 

Two  generations  of  the  Production  Schedule  file  will  be 
used  to  produce  such  reports.  They  will  be  one  month  (or 
two  weeks)  apart  according  to  the  frequency  of  printing  of 
a  report.  The  progress  in  a  job  will  be  computed  by  subtract¬ 
ing  total  expended  hours  recorded  in  the  previous  generation 
of  the  file  from  hours  expended  in  the  same  job  until  the 
present  time.  This  progress  will  be  analyzed  to  determine 
if  it  is  satisfactory.  The  criteria  for  classifying  a 
customer  order  as  an  exception  will  have  to  be  set  up  by  the 
production  control  people.  Some  possible  criteria  are  listed 
below: 

1.  Expended  hours  exceed  standard  hours  by  more  than  20 
percent . 

2.  The  proportion  of  expended  hours  relative  to  standard 
hours  is  less  than  70  percent  of  the  proportion  of 
time  that  elapsed  relative  to  the  total  duration 
required  for  completion  of  the  job. 

3.  More  than  20  days  have  passed  since  the  latest 
required  finish  date  and  the  job  has  not  been 
finished  yet  (or  not  reported  as  finished). 

This  report  will  also  be  produced  in  two  different 
sequences:  a  listing  of  all  exceptional  job  orders  and 

another  listing  by  shops/job  orders. 

The  inputs  to  the  system  will  come  from  two  sources: 
transactions  reported  by  the  production  control  department 


and  inputs  that  were  generated  by  other  applications.  Among 
the  last  group  are  inputs  about  standard  hours  from  the  Master 
Data  Record  (MDR)  file,  expended  labor  hours  from  the  Sorted 
Labor  Transaction  (SLT)  file  and  induction  data  from  the 
Sorted  WIP  (work  in  process)  History  Activity  file  [23].  The 
transactions  that  will  be  written  especially  for  the  system 
are  intended  to  maintain  information  about  planned  induction 
quantities  and  scheduled  dates  of  the  different  job  orders. 
They  will  also  allow  changes  in  the  status  of  job  orders. 

The  transactions  will  allow  reporting  on  individual  job 
orders  or  on  a  whole  FIC.  This  last  option  is  especially 
needed  for  reporting  a  new  production  schedule.  A  simple 
data  entry  program  can  simplify  the  process  of  reporting  the 
transactions  mentioned  above.  Figure  15  depicts  the  layouts 
of  the  different  inputs  that  the  system  will  process.  The 
MDR  data  will  be  extracted  directly  by  the  PCS  file  mainten¬ 
ance  module  and  therefore  the  standard  hour  information  will 
not  show  up  in  these  layouts.  The  different  transactions 
will  be  edited  by  an  input  edit  program  that  will  check  the 
different  fields  for  validity.  Other  fields,  like  the  job 
order  and  transaction  code,  will  be  examined  later  by  the 
file  maintenance  program  to  make  sure  that  when  the  code 
specifies  an  update,  the  job  order  already  exists. 

To  perform  its  functions,  the  system  will  maintain  a 
PCS  file  that  will  store  the  information  about  the  various 
job  orders.  The  file  will  be  a  direct  access- variable- length 
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Figure  IS:  PCS  Input  Formats 


record  file.  A  logical  record  will  consist  of  three  basic 
structures : 

1.  A  header  for  each  F IC/FY/Quarter . 

2.  Job  order  trailers  fo.  jobs  belonging  to  the  above 
FIC/FY/Quarter . 

3.  Shop  trailers  for  shops  participating  in  the  above  job 
order . 

Each  such  record  will  store  the  information  about  a  particular 
FIC  which  is  scheduled  for  a  specific  quarter  (i.e.,  if  the 
file  covers  a  period  of  one  year,  there  may  be  1  to  4  differ¬ 
ent  records  with  the  same  FIC) .  The  tree  structure  of  a 
logical  record  is  depicted  in  Figure  16.  The  file  will  be 
accessed  by  FIC/FY/Quarter.  However,  this  index  and  the 
translation  subroutines  from  FIC  to  I I C  and  vice  versa  and 
from  job  order  to  I I C  will  allow  direct  access  to  the  file  bv 
either  job  order  or  IIC,  fiscal  year  and  quarter.  Figure  17 
depicts  the  layout  of  each  one  of  the  PCS  record  components. 

The  header  information  contains  information  about  a  FIC 
that  is  scheduled.  Each  job  order  trailer  represents  one  of 
the  specific  job  orders  in  which  an  IIC  belonging  to  the  FIC 
will  be  overhauled.  The  job  order  trailer  contains  summary 
data  about  the  job  order  and  allows  access  to  its  shop  trail¬ 
ers  which  contain  information  (namely  standard  and  expended 
hours)  about  each  shop  that  participates  in  the  job. 

The  status  of  a  FIC  or  a  job  order  represents  the  situa¬ 
tion  of  a  group  or  a  specific  job  respectively.  The  status 
can  be  one  of  the  following: 


-  1 
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Figure  16:  PCS  data  structure. 
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Figure  17:  PCS  record  layout 


blank  -  The  job  has  not  been  started  yet. 


"W"  -  The  job  is  in  process  (i.e.,  expended  hours 

are  positive) . 

"C"  -  The  job  has  been  cancelled. 

"F"  -  The  job  has  been  finished. 

Since  the  FIC  header  represents  a  set  of  job  orders,  its  status 
will  reflect  the  status  of  its  composite  set  of  job  orders. 

The  header  status  will  be  changed  to  "W"  when  the  first  job 
has  been  started.  Similarly,  it  will  be  "F"  only  after  the 
last  job  has  been  finished.  The  status  can  be  changed  to  "C" 
only  by  a  status  reporting  transaction  (see  Figure  15).  Con¬ 
sequently,  the  "date  of  status"  field  will  represent  the  date 
of  the  last  change  in  status. 

The  production  control  subsystem  software  will  include  the 
following  modules: 

1 .  Input  Edit 

This  module  will  validate  individual  data  fields  and 
will  print  out  records  that  contain  erroneous  data. 

2 .  File  Maintenance 

This  involves  performing  further  validity  checks  on 
good  records  from  the  previous  step  and  subsequently  updating 
of  the  PCS  file.  The  FIC  transactions  will  be  the  first  to 
update  the  file.  These  transactions  will  cause  the  creation 
of  new  FIC  headers,  and  then  job  order  trailers  with  predicted 
quantities  (based  on  relative  frequencies  of  IIC's)  and  shop 
trailers  with  standard  hours  from  the  MDR.  Subsequently, 
other  transactions  will  update  or  add  information  to  that 
which  was  generated  by  the  FIC  transaction. 


Queries . 


j  . 

4 .  Report  Generators. 

Production  schedule  listings  and  exception  reports. 

Figure  18  describes  the  information  network  and  the  data 
flow.  It  also  shows  how  the  induction  data  for  updating  the 
BOM  file  is  extracted  from  the  PCS  file. 

One  advantage  introduced  by  the  proposed  PCS  is  the 
continuity  of  the  production  schedule,  i.e.,  a  job  order 
stays  alive  until  it  is  finished  or  cancelled.  In  this  way, 
customer  orders  that  were  not  completed  in  the  scheduled 
quarter  are  carried  over  to  subsequent  quarters  until  they 
are  completed.  This  saves  the  work  of  reevaluating  the  re¬ 
quirements  for  end-items  when  preparing  each  quarter's 
production  schedule. 

The  production  control  system  described  above  can  be 
run  on  the  500  Department  ADP  system  that  is  used  to  run  the 
temporary  MRP  system.  Weekly  runs  appear  to  be  more  than 
adequate  at  this  time.  On-line  updates  may  be  required  in 
the  future,  however. 

It  is  recommended  that  implementation  begin  with  only 
transaction  updating,  even  though  such  information  may  exist 
in  a  mechanized  form  in  another  part  of  the  system.  While 
this  may  result  in  extra  manual  work,  it  has  the  advantage 
of  simplifying  and  increasing  the  involvement  of  the  produc¬ 
tion  control  people  in  the  system  evolution. 


109 


Figure  18:  The  Production  Control  Subsystem  (PCS). 
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E.  DATA-BASE  DESIGN 


The  additional  data  files  that  are  required  for  the  MRP 
application  are  designed  below. 

1.  The  BOM  File 

Carrying  out  a  production  schedule  requires  personnel, 
facilities  and  money  (for  contracting  out  repair  of  special 
components)  as  well  as  materials.  The  basic  MRP  technique 
computes  only  material  requirements.  However,  it  will  be 
desirable  to  incorporate  in  the  same  file  the  information 
about  all  required  resources  and  thereby  provide  a  tool  for 
comprehensive  production  planning. 

When  considering  all  resources  (except  facilities), 
the  information  about  each  end- item  should  contain  the 
following : 

1.  End-item  inf ormat ion- - inc luding  money  for  contracting 
out . 

2.  Consumable  materials  information. 

3.  Labor  hours  information. 

This  implies  that  the  records  for  each  IIC  should 
have  a  tree  structure  with  a  root,  being  a  header  containing 
the  end- item  information  and  two  branches,  one  for  materials 
and  the  other  for  labor  hours.  Each  branch  would  be  a  set 
of  fixed  length  records  representing  either  a  material  or  a 
shop's  labor  hours.  Figure  19  depicts  the  structure  of  an 
IIC's  logical  record. 


Ill 


Header 


"Consumable"  Trailer 

Figure  19:  BOM  Data  Structure 


As  shown  in  Figure  19,  for  each  IIC  there  will  be 
one  header,  one  consumable  trailer  per  consumable  item  and 
one  shop  trailer  per  participating  shop.  The  information  in 
the  header  will  allow  access  to  the  trailers  by  either  having 
there  a  pointer  or  the  number  of  different  trailers.  Figure 
20  depicts  the  layout  details  of  the  header  and  trailers. 

An  important  factor  in  designing  the  BOM  is  the  fact 
that  the  NARF  is  involved  in  maintenance  rather  than  produc¬ 
tion.  The  implication  of  that  fact  is  that  instead  of  having 
a  BOM  that  experiences  only  addition  of  new  IIC's,  as  in  the 
case  of  manufacturing,  the  file  will  require  changes  to 
existing  data,  namely  the  replacement  factors.  Also,  there 
must  be  a  distinction  between  estimated  replacement  factors 
(representing  new  or  modified  items)  and  items  that  have 
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Figure  20:  BOM  Record  Layout 


already  been  overhauled.  The  process  of  maintaining  the 
replacement  factor  data  is  described  in  Appendix  D. 

The  file  will  be  an  index- sequential  file  with  the 
IIC  being  the  access  key.  When  only  the  FIC  is  known,  access 
is  possible  by  using  the  FIC  to  IIC  translation  table.  Appro¬ 
priate  read/write  functions  will  make  it  simple  for  applica¬ 
tion  programs  to  access  the  file. 

The  implementation  of  the  shops  branch  in  the  BOM  is 
independent  of  the  other  parts.  Since  the  integration  of  the 
inventory  and  production  control  applications  at  NARF  Alameda 
is  not  going  to  take  place  in  the  near  future,  it  is  recom¬ 
mended  that  the  implementation  of  this  part  be  postponed 
until  the  materials  segment  works  properly  and  the  organiza¬ 
tion  is  ready  to  manage  the  rest.  Deletion  of  the  shop  data 
can  simply  be  achieved  by  reporting  only  materials  data  to 
the  system.  This  will  create  IIC  records  with  no  shop 
trailers.  Because  the  shops  branch  will  not  be  implemented 
with  the  rest  of  the  system,  this  part  will  not  be  included 
in  the  file  maintenance  design. 

2 .  FIC  to  IIC  Translation  Table 

The  intent  of  this  file  is  to  provide  the  data  for 
translating  a  FIC  end-item  identification  into  the  specific 
IIC's  that  comprise  it.  The  file  also  allows  the  opposite 
translation  from  IIC  to  FIC.  Finally,  the  file  provides  the 
relative  frequency  with  which  the  specific  IIC's  are  expected 
to  be  inducted.  This  last  element  is  vital  for  the  transla¬ 
tion  of  a  production  schedule  by  FIC  into  an  IIC  schedule. 
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The  file  will  be  composed  of  fixed  length  records, 
one  record  per  IIC.  The  organization  of  the  file  will  be 
such  that  all  records  for  one  FIC  will  be  organized  sequen¬ 
tially.  Therefore,  to  find  the  composition  of  a  FIC,  one 
has  to  access  the  file  and  read  it  sequentially  until  the 
record  contains  a  different  FIC.  Figure  21  depicts  the 
organization  and  record  layout  of  the  file. 
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Figure  21:  FIC  to  IIC  translation  file  record 
layout. 
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3.  Other  Files 


A  file  that  has  not  been  designed  yet  is  the  inventory 
status  file.  This  file  should  contain  information  about  all 
NSN's  involved  in  the  requirements  forecasting  process.  The 
easiest  way  to  get  that  data  will  be  to  get  an  extract  from 
NSCO's  MSIR  which  will  contain  all  records  related  to  items 
stored  in  the  RSS.  Using  that  file  will  save  its  maintenance 
by  the  NARF.  Since  the  information  about  the  quantities  is 
not  used  by  the  MRP  application,  it  will  be  sufficient  to  have 
a  new  copy  of  the  file  each  week  or  two.  Figure  22  depicts 
a  layout  of  this  file  that  will  satisfy  the  proposed  applica¬ 
tion.  Any  similar  structure  that  is  readily  available  is  also 
satisfactory . 


NSN 

COG 

U/I 

U/P 

Nomenclature 

RSS  Qty 
On  Hand 

RSS  Qty 
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Note :  Any  other  structure  that  contains  these  fields  is 
acceptable. 

Figure  22:  MSIR  Extract  Record  Layout. 

Another  file  that  will  change  with  the  implementation 
of  the  proposed  system  is  the  MRP  forecast  file.  The  infor¬ 
mation  that  was  added  to  the  file  for  current  production 
control  needs  will  no  longer  be  required.  However,  some 
method  will  still  be  needed  for  computing  the  distribution 
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of  the  gross  requirements.  Thus,  the  appropriate  new  struc¬ 
ture  is  shown  in  Figure  23. 
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63  65 
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*  Replacement  factor  -  total  requirement/ ( I IC  Scheduled 
Quantity  *  Installed  Quantity). 


Figure  23:  MRP  forecast  record  layout 


F.  SOFTWARE  DESIGN 

The  software  of  the  proposed  system  will  consist  basically 
of  the  same  modules  as  the  temporary  system.  The  differences 
are  in  the  contents  and  in  the  set  of  functions  that  will  be 
used  by  the  different  modules.  Figure  24  depicts  the  block 
diagram  of  the  main  software  modules. 

1 .  File  Maintenance 

This  module  consists  of  the  programs  to  maintain  the 
BOM  file  and  the  FIC  to  IIC  translation  table.  The  MSIR  is 
not  maintained  but  reproduced  whenever  needed  and  the  Material 
Forecast  file  is  generated  by  the  requirements  generation 
module  and  updated  by  queries. 
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Figure  24:  Software  Modules 


a.  BOM  File  Maintenance 

The  intent  of  this  module  is  to  update  the  BOM 
file  with  respect  to  the  composition  of  the  end-items,  the 
replacement  factors  of  the  components,  and  the  labor  hours 
and  shops  participating  in  the  job. 

The  information  that  will  update  the  BOM  will 
come  from  two  sources: - 

1.  Transactions  written  by  the  material  planners.  These 
are  intended  to  introduce  new  items  or  to  update  the 
file  after  technical  modifications  have  taken  place. 

2.  Expended  materials  and  labor  hours.  This  historical 
data  will  be  used  to  update  previous  data  in  the  file. 

The  file  maintenance  process  consists  of  three 
steps  as  depicted  in  Figure  25.  The  first  step  deals  with 
collection  of  the  various  inputs  Conduction  data,  expended 
materials  and  labor  hours  and  the  transactions  written  by  the 
planners)  into  one  file.  This  program  receives  a  parameter 
that  tells  the  program  the  date  of  the  previous  BOM  maintenance 


« 


118 


run  and  scans  the  production  schedule  file  for  jobs  that  were 
completed  after  that  date.  For  each  completed  job  the  program 
writes  to  the  output  file  one  induction  data  record  (type  1 
record  as  shown  in  Figure  26)  and  a  set  of  shop  data  records 
(type  8  records).  These  latter  records  contain  expended 
hours  by  one  shop  on  the  specific  job.  At  the  same  time  the 
job  number  is  entered  into  a  table  of  completed  jobs.  When 
the  end  of  the  production  schedule  is  reached,  the  table  is 
used  as  a  look-up  table  for  extracting  expended  materials  from 
the  DHF  and  the  RSF.  For  each  record  that  belongs  to  a  job 
that  is  in  the  table,  the  program  writes  a  type  4  record 
(requisitioning  data) . 

The  second  step  simply  sorts  all  inputs  and  pre¬ 
pares  them  for  the  final  step  in  which  the  transactions  are 
validated  and  used  to  update  the  file.  The  sorting  is  based 
on  columns  1-22  (IIC,  record  type,  NSN/shop,  date).  Ascending 
order  will  assure  that  the  transactions  with  header  informa¬ 
tion  will  be  processed  first,  and  later  transactions  for 
materials  and  labor  hours  (i.e.,  in  the  same  order  that  the 
trailers  are  organized  in  the  file). 

Type  1  transactions  are  also  used  to  create/add 
new  IIC's  to  the  BOM  file.  Type  3  and  type  6  transactions 
provide  the  additional  consumable  items  and  labor  hours  in¬ 
formation  required  to  forecast  requirements.  Types  1,  4  and 
8  transactions  are  used  to  compute  actual  average  quantities 
of  materials  and  labor  hours. 
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As  mentioned  earlier,  the  transactions  are  sorted 
by  IIC  and  by  the  type  of  header/ trai ler  the  data  in  the 
transaction  is  to  update.  Consequently,  the  update  process 
treats  each  IIC  that  has  transactions  individually,  starting 
with  creating/updating  the  header,  creating/updating  consum¬ 
able's  trailers  and  finally  creating/updating  shop  trailers. 

The  process  of  updating  an  IIC  begins  with  reading  a  transac¬ 
tion  that  contains  an  IIC  different  than  the  IIC  in  the 
previous  transaction.  This  causes  an  access  to  the  BOM  in  an 
attempt  to  read  the  IIC's  old  data.  If  the  IIC  existed,  the 
transactions  are  considered  as  changes;  otherwise  they  will 
create  a  new  IIC  entry  in  the  BOM.  In  this  case  there  is  a 
requirement  to  have  additional  transactions  with  material/shop 
data. 

The  process  of  updating  trailers  is  also  designed 
to  treat  individual  trailers  separately  (i.e.,  one  consumable 
or  one  shop  at  a  time).  The  induction  data  transaction  is 
processed  first  and  all  it  does  is  to  save  the  induction 
quantity  in  memory.  Subsequently,  material  estimate  trans¬ 
actions  (or  shop  estimates)  simply  update  the  appropriate 
fields  in  the  trailer,  whereas  for  a  requisitioning  (or  shop 
data)  transactions  the  expended  quantity  is  computed  and 
divided  by  the  induction  quantity  to  give  a  new  average  con¬ 
sumption.  This  average  is  exponentially  smoothed  (see 
Appendix  D)  witn  the  old  data  and  the  updated  information  is 
saved  in  memory.  In  the  course  of  processing  these  transactions 
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the  program  will  also  have  to  verify  that  all  data  fields 
contain  valid  data. 

Another  function  that  the  program  performs  is  to 
detect  exceptional  replacement  factors.  Whenever  the  differ¬ 
ence  between  the  old  and  the  new  factors  is  greater  than  0.2 
(or  any  other  value  that  can  be  selected)  the  program  will 
print  the  data  in  the  input  edit  and  exceptions  report.  This 
report  will  have  to  be  checked  and,  if  there  was  an  error,  the 
appropriate  correction  should  be  made. 

Figure  27  describes  the  main  functions  that  will 
be  performed  by  the  BOM  file  update  program  when  treating  an 
IIC.  Although  the  flow  chart  appears  to  contain  many  details, 
it  is  intended  as  a  summary  rather  than  the  actual  flow  chart 
of  the  program.  It  must  also  be  remembered  that  the  labor 
hours  branch  will  be  implemented  at  a  later  time  so  that  it 
is  too  early  to  go  into  more  details  than  are  needed  to 
describe  the  general  process. 

The  complete  BOM  file  maintenance  run  will  be 
executed  once  per  quarter.  This  run  will  take  place  a  short 
time  before  the  workload  conference  so  that  an  up-to-date  BOM 
file  will  be  available  for  generating  the  material  require¬ 
ments.  However,  runs  that  just  process  transactions  reported 
by  the  planners  can  be  run  at  any  time  so  that  new  data  would 
not  have  to  wait  up  to  three  months  before  being  processed. 
Weekly  runs  for  such  purposes  are  probably  sufficient. 
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Figure  27:  (continued) 


Figure  27:  (continued) 
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b.  Maintenance  of  the  FIC  to  I I C  Translation  Table 

The  maintenance  of  this  file  has  two  goals :- 

1.  Update  the  file  with  new  end-items. 

2.  Update  the  relative  frequency  of  IIC's. 

The  information  from  the  Quarterly  Family  Tape 
(QFT)  will  be  used  to  keep  track  of  all  existing  end-items. 
This  file  is  maintained  by  ASO  and  is  delivered  to  users  on 
a  quarterly  basis.  It  contains  one  record  per  1 1 C  and  each 
such  record  contains  the  FIC  to  which  that  I I C  belongs. 

The  relative  frequency  of  IIC's  will  be  updated 
by  the  induction  data.  A  record  will  be  provided  for  each 
induction,  containing  the  IIC  that  was  inducted,  the  induc¬ 
tion  quantity,  and  the  FIC.  The  input  will  be  sorted  by  FIC 
and  IIC  and  by  ascending  record  type  ("1"  for  QFT  records  and 
"2"  for  induction  data). 

The  principle  used  in  updating  the  file  is  to 
update  all  information  about  a  FIC  as  one  unit.  Therefore, 
for  FIC's  that  have  transactions,  their  records  from  the  old 
file  are  read  into  an  array  in  memory.  Then  the  transactions 
update  appropriate  quantities  or  open  new  entries  for  new 
IIC's  and  at  the  end  of  the  FIC, updated  records  are  written 
to  a  new  file.  FIC's  that  have  no  transactions  are  just 
copied  from  the  old  to  the  new  file. 

Figure  28  depicts  the  maintenance  run  and 
Figure  29  is  the  flow  chart  for  updating  one  FIC. 
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Figure  28:  FIC  to  IIC  Translation  Table  File  Maintenance 


29:  Updating  FIC  Data 
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2 .  Queries 


Implementation  of  the  proposed  system  will  require 
conversion  of  the  temporary  system  software  to  fit  the  new 
data-base.  The  use  of  the  MRP  subroutine  will  simplify  signif¬ 
icantly  the  query  program  and  will  usually  require  a  simple 
"driver"  program  that  will  prompt  the  user  and  translate  his 
inputs  into  appropriate  MRP  subroutine  calls. 

To  facilitate  use  of  the  system,  "query  numbers"  will 
be  assigned  to  each  type  of  query.  They  will  allow  the  user 
to  choose  the  query  type  dynamically.  In  the  selection  mode 
the  system  will  display  all  alternate  queries  available  for 
use  and  let  the  user  specify  his  choice.  This  will  then  cause 
branching  to  the  appropriate  module  that  will  retrieve  the 
requested  information. 

Figure  30  depicts  the  block  diagram  of  the  query 

module . 

3 .  Requirements  Generation 

This  module  will  be  significantly  different  from  the 
one  in  the  temporary  system  because  the  proposed  requirements 
generation  program  will  consider  job  orders  that  are  already 
in  process  and  because  the  use  of  the  MRP  subroutine  will 
simplify  the  program. 

The  generation  of  the  requirements  will  consist  of 
several  steps,  as  shown  in  Figure  31.  The  first  step  scans 
the  production  schedule  file  to  extract  and  build  a  list  (in 
memory  or  as  a  temporary  file)  of  all  job  orders  that  will 
be  worked  on  during  the  coming  quarter.  This  means  that  an 
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Figure  30:  Query  Module  Block  Diagram 


Figure  31:  Material  Requirements  Generation  Run 
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entry  will  be  opened  for  each  job  order  whose  planned  period 
falls  in  the  coming  quarter  and  whose  status  is  blank,  "IV"  or 
"P".  Each  such  entry  (or  record)  will  contain  the  job  order 
(which  contains  the  IIC)  and  the  scheduled  quantity. 

The  next  step  will  use  those  job  orders  as  a  table  to 
extract  from  the  DHF  and  RSF  the  materials  that  have  already 
been  expended  in  continuing  job  orders.  The  output  of  this 
step  is  the  Expended  Materials  file. 

The  third  step  is  the  actual  preparation  of  the  MRP 
Forecast  file.  In  this  phase  the  program  issues  calls  to  the 
MRP  subroutine  and  transforms  the  output  from  the  subroutine 
into  records  with  the  structure  of  the  MRP  Forecast  file. 

After  the  material  planners  finish  updating  the  MRP 
Forecast  file,  the  computation  of  the  requirements  for  each 
consumable  item  is  performed.  To  do  that,  the  intermediate 
file  that  subroutine  MRP  needs  is  regenerated  from  the  final 
MRP  forecast  file  and  both  the  intermediate^fqle  and  the 
Expected  Materials  file  are  input  to  the  program  which  issues 
a  terminating  call  to  subroutine  MRP.  The  subroutine  then 
uses  the  proposed  model  to  generate  the  final  requirements 
forecast.  This  output  is  formatted  into  RSS  level  setting 
transactions  (AOA  transactions). 

4 .  General  Purpose  Subroutines 

The  MRP  application  involves  several  functions  that 
will  be  performed  by  several  programs.  It  will  be  very  useful 
2 

They  can  modify  only  the  "total  requirement  quantity" 
field--see  Figure  23,  columns  66-69. 
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to  have  those  modules  shared  by  the  different  programs,  thereby 
saving  programming  effort  and  assuring  consistency. 

A  set  of  such  functions  are  the  read/write  functions. 
The  application  involves  several  var iab le - length- record  files 
which  may  present  a  problem  to  novice  programmers.  The  prob¬ 
lem  can  be  solved  by  a  set  of  I/O  routines.  Each  routine  will 
perform  either  read  or  write.  It  will  be  called  with  param¬ 
eters  that  will  specify  the  program's  need  and  will  return 
(or  write)  a  complete  logical  record  or  a  required  header/ 
trailer.  Some  additional  work  can  be  saved  by  having  the 
various  data  structures  in  software  libraries.  Those  s  true  - 
tures  would  be  copied  by  user  programs  and  would  save  the 
definition  by  each  one. 

Another  subroutine  that  will  be  required  is  a  sub¬ 
routine  that  accepts  the  mean  and  variance  of  a  random  var¬ 
iable  that  has  a  Normal  distribution,  and  a  desired  cumulative 
probability  and  provides  the  value  that  satisfies  that  proba¬ 
bility.  This  function  would  not  have  to  be  written  by  local 
personnel  but  can  be  bought  from  software  vendors.  This 
function  is  required  for  the  application  of  the  proposed 
model . 

Another  required  subroutine  is  one  which  identifies 
the  IIC  that  is  being  overhauled  in  a  given  job  order.  The 
IIC  is  contained  in  the  job  orders  but  its  position  is  dif¬ 
ferent  according  to  the  production  program  the  job  belongs  to. 
By  maintaining  a  table  of  the  positions  of  the  IIC  in  various 
job  numbers,  one  can  easily  identify  an  IIC  from  a  job  order. 
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This  function  will  be  needed  to  allow  access  to  the  production 
schedule  or  to  the  BOM  file  when  only  a  job  order  is  given. 

G.  SYSTEM  CC  MF IGURAT ION 

The  intent  of  this  section  is  to  identify  the  computer 
resources  that  will  be  required  for  running  the  proposed  MRP 
application.  The  sources  that  were  utilized  in  estimating 
the  resources  are: 

1.  The  information  about  the  temporary  MRP  application. 

2.  Comparison  of  complexities  of  the  existing  and  proposed 
software  and  data-base. 

5.  Personal  experience  of  the  author  with  similar  systems. 

This  analysis  takes  into  account  an  annual  file  size  and 
processing  growth  factor  of  10  percent  and  assumes  a  useful 
life  period  of  ten  years  [26]. 

1 .  On-Line  Storage 

On-line  storage  is  required  for  the  data-base,  work 
areas,  and  software  libraries.  The  last  two  elements  can  be 
ignored  here  because  of  their  relative  small  size  and  also 
because  they  are  shared  by  other  applications. 

Table  III  shows  estimates  of  the  net  sizes  of  the 
various  files.  When  considering  inter-record  gaps  of  30  bytes 
and  allowances  of  10  percent  for  overhead  and  indices,  the 
required  storage  becomes  (118924  +  30  x  )  x  1.1  =  207  MB. 

When  the  future  growth  during  the  useful  life  of  the  system 
is  included,  the  requirement  at  the  end  of  ten  years  becomes 

207  x  (1.1)^  a  488MB  for  on-line  storage. 
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TABLE  III 


File  Sizes 


File  Name 

"Record"  Name 

#  of  Records 

Record  Length 
(Bytes) 

Net  Size 
(K- Bytes) 

BOM 

IIC  header 

47 

658 

Consumable 

Trailer 

37 

25,900 

Shop  Trailer 

1  1 1  1 

20 

3,400 

FIC  to  IIC 

IIC  Record 

14,000 

35 

490 

Translation 

Table 

MRP  Forecast* 

Consumable 

Record 

1,000,000 

77 

77,000 

MSIR  Extract* 

NSN  Record 

40,000 

57 

2,280 

Production 

FIC  Header 

20,000 

44 

880 

Schedule* 

Job  Order 
Trailer 

28,000 

42 

1,176 

Shop  Trailer 

340,000 

21 

7,140 

Total 

_ 

2,306,000 

118,924 

*  Numbers  of  records  were  inflated  to  represent  required  capacity 
at  war  time. 


This  storage  quantity  is  less  than  30  percent  of  the  1200  MB 
disc  storage  that  ASKARS  will  have  as  a  minimum  [22:3.3.8]. 

2 .  Off-Line  Storage 

The  required  off-line  capacity  imposes  no  constraint 
except  to  tape  drives.  Two  tape  drives  will  allow  copying  of 
files,  taking  back-ups,  and  running  the  programs  that  will 
usually  have  input  (transaction)  tapes. 

3 .  Main  Memory 

Main  memory  is  required  for  programs  (and  their  I/O 
buffers)  that  are  run  simultaneously.  Since  file  maintenance 
and  queries  would  not  run  concurrently,  main  memory  require¬ 
ments  are  computed  for  the  file  maintenance  module  and  the 
general  purpose  subroutines.  As  Appendix  C  shows,  the  length 
of  those  modules  is  2000  +  450  =  2450  high  level  language 
statements.  Assuming  an  average  of  10  machine  instructions 
per  statement  and  an  average  of  6  bytes  per  instruction,  the 
total  main  memory  amounts  to  2450  x  10  x  6  -  147000  Bytes. 

When  adding  buffers  for  the  BOM  file  (=  8.8KB),  the  production 
schedule  file  (5  KB)  FIC  to  IIC  translation  table  (35  bytes) 
and  transactions  (80  bytes),  at  least  165  KB  are  needed  in 
addition  to  the  memory  resident  operating  system  modules. 
However,  it  must  be  noted  that  systems  whose  operating  system 
provides  virtual  memory  may  utilize  less  real  memory. 

4 .  Processing  Time 

When  computing  processing  time,  one  has  to  distinguish 
between  three  different  modes  of  operation  during  a  quarter, 
each  of  which  requires  different  processing  capacities. 
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The  highest  capacity  is  required  when  the  mainte¬ 
nance  of  the  BOM  file  takes  place  (once  per  quarter  in  the 
third  month)  and  when  the  MRP  Forecast  file  and  RSS  level 
setting  transactions  are  generated.  A  lower  capacity  is 
required  for  maintaining  the  Production  Schedule  file  (at 
least  once  a  week).  The  lowest,  but  most  frequently  required 
capacity  is  for  the  queries. 

This  imposes  a  changing  load  on  the  system  and  it 
will  require  timing  the  execution  of  various  programs  to 
prevent  temporary  peak  loads. 

In  estimating  the  total  processing  time  for  MRP  and 
PCS,  the  following  assumptions  are  made: 

1.  10  Machine  instructions  per  statement. 

2.  Average  clock  pulses  per  instruction  =  12. 

3.  Clock  rate  =  3  MHZ. 

4.  During  file  maintenance,  one-half  of  all  statements 
are  executed  for  each  transaction. 

5.  During  queries,  one-fourth  of  all  statements  are 
executed  once  per  query. 

6.  In  report  generating  type  programs,  each  statement 
is  executed  once. 

Applying  assumptions  1  through  3  gives  an  average 
statement  execution  time  of  10  x  12  x  j  -  40  psec. 

When  using  this  average  execution  time  with  the  input 
rates  from  Appendix  B,  the  program  sizes  from  Appendix  C, 
and  the  processing  capacity  as  shown  in  Table  IV,  and  when 


applying  the  10  percent  annual  growth  factor,  the  total 
quarterly  execution  time  during  the  tenth  year  of  operation 
amounts  to: 


483450  x  10°  x  40  x  10 


-6 


.statements.  . 
qtr  '  '■ 


sec 
stat . 


1  X 

'  TWO  x 

.hours . 
^sec  J 


Cl- 1)9 


=  12.7  hours  per 
quarter . 


During  the  first  year  of  operations  the  system  will 
require  only  5.00  hours  per  quarter. 

5 .  Conclus ions 

The  resources  that  are  required  for  running  the  MRP 
application  are  relatively  small.  The  computations  above  have 
taken  into  account  not  only  the  MRP  system  but  also  the  PCS. 
Even  including  future  growth,  the  processing  time  does  not 
justify  devoting  a  computer  to  this  application. 

The  conclusion  is  that  the  application  should  be  run 
on  an  existing  system  and  the  system  that  appears  to  be 
appropriate  is  ASKARS.  The  reasons  for  selecting  ASKARS' 
computer  system  are  three- fold: 

1.  The  MRP  system  plans  materials  which  are  carried  and 
later  handled  by  ASKARS. 

2.  ASKARS  is  a  redundant  system  and  therefore  the  addi¬ 
tional  load  on  the  system  would  be  insignificant. 

3.  The  ASKARS  system  will  hopefully  have  skilled  ADP 
personnel  (as  opposed  to  the  PDP  11/70  on  which  the 
temporary  system  runs)  that  could  handle  such  a  project. 
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H.  COSTS  AND  BENEFITS 


The  purpose  of  the  following  analysis  is  to  compare  the 
costs  involved  in  implementing  the  proposed  system  and  to 
explore  the  benefits  it  will  provide. 

The  costs  involved  in  implementation  of  the  MRP  system 
are  of  two  types:  one-time  development  costs  (software 
development)  and  recurring  costs  for  software  and  hardware 
maintenance,  supplies,  personnel,  and  payments  for  computer 
time.  Although  ASKARS'  processing  and  peripheral  equipment 
have  already  been  accounted  for  ("sunk  cost")  we  will  assume 
in  this  analysis  that  there  is  a  capital  cost  associated  with 
using  the  MRP  application  in  ASKARS  and  that  it  can  be  computed 
according  to  the  proportion  of  CPU  time  the  MRP  uses  relative 
to  the  total  CPU  time  available.  We  will  also  assume  that 
the  annual  depreciation  cost  of  this  equipment  is  10  percent 
of  the  purchase  price.  Consequently,  the  annual  allowance 
for  hardware  is 

HC  =  [PC/10]  x  [ Tj /T ^ ] 

where:  HC  =  annual  allowance  for  MRP  hardware  costs 

PC  =  purchase  costs  of  the  complete  system 

T,  =  CPU  time  for  MRP.  We  will  assume  an  average 
of  10  hours  per  quarter  (see  section  G.4  of 
this  chapter). 

T2  =  total  CPU  time  available  per  quarter.  Since 
there  are  two  processors, 

T2  ■  2  x  90  x  8  =  1440  hours. 

Since  the  procurement  of  the  ASKARS  system  is  now  in  the 
bidding  phase  we  will  assume  that  the  cost  of  the  ADP  equipment 


is  50  percent  of  the  total  cost  of  the  ASKARS  system.  The 
latter  is  estimated  to  he  $2,513,500  [26];  consequently,  the 
cost  of  the  ADP  equipment  in  that  system  would  be  approxi¬ 
mately  $1,257,000.  Using  these  figures,  the  hardware  costs 
would  amount  to  less  than  $1000  per  year. 

Allowing  10  percent  of  that  amount  for  hardware  mainte¬ 
nance,  the  MRP's  share  of  hardware  maintenance  costs  will  be 
approximately  $100  per  year. 

Software  maintenance  will  be  assumed  to  require  one 
programmer  and  1/6  of  one  analyst  (based  on  development  per¬ 
sonnel).  In  addition,  the  system  will  need  two  clerks  for 
handling  inputs  and  outputs.  Using  an  average  annual  salary 
of  $30,000  a  year,  including  fringe  benefits,  the  personnel 
costs  for  software  maintenance  and  operations  would  be: 

(1  +  1/6  +  2)  x  30,000  =  $96,000  per  year. 

When  using  the  software  development  times  from  Appendix 
C  and  the  above  annual  salary,  the  development  and  training 
expenses  amount  to 

(ZJL5. ± -lfL2-L  x  30,000  =  $247,250 

To  that  we  have  to  add  processing  time  of  approximately  thre 
months  during  the  development  period  (HC  x  4/2  *  330)  to  get 
a  total  of  $247,580  for  development  costs,  or  approximately 
$25,000  annually  to  be  added  to  the  recurring  costs.  When 
adding  all  these  costs,  we  find  that  the  annual  costs  of 
running  the  system  are  $122,100. 


The  benefits  from  implementing  the  system  are  more  diffi¬ 
cult  to  measure,  although  relatively  easy  to  identify.  The 
system  will  provide  the  material  planners  a  good  data  base  on 
which  they  can  base  their  decisions.  It  will  also  save  them 
time  by  providing  the  necessary  reports  and  inquiry  capa¬ 
bilities  (although  this  is  not  intended  to  totally  replace 
their  being  in  the  shops!).  The  system  will  also  provide  a 
better  requirements  forecast  and  thereby  improve  availability 
of  materials  for  repair  and  availability  of  ready- for- issue 
items  that  would  not  be  delayed  in  the  process  of  repair. 
Another  area  of  savings  is  in  workers'  time.  Because  of 
improved  availability  of  materials,  work  stoppages  are  ex¬ 
pected  to  go  down,  thereby  reducing  the  need  for  "backrobbing" 
(i.e.,  removal  of  parts  from  an  aircraft/component  for  use  on 
another  aircraft/component  with  an  earlier  scheduled  comple¬ 
tion  date  [21:16]). 

Another  very  important  advantage  of  introducing  MRP  is 
the  fact  that  the  improved  forecast  should  lower  the  amount 
of  money  tied  up  in  inventories  and  should  release  that  money 
for  use  elsewhere. 

The  factors  that  have  been  mentioned  above  gave  a  quali¬ 
tative  description  of  the  benefits;  quantifying  some  of  them 
will  clarify  the  description.  During  the  period  1  April  1978 
thru  31  March  1979  NARF  Alameda's  work  centers  charged  21,186 
production  delay  hours  to  backrobbing.  These  hours  represent 
a  cost  of  more  than  $860,000  [21:16]  per  year.  Expenditures 
on  material  planners'  salaries  amount  to  approximately 


122  x  30,000  =  $3,660,000  a  year.  Saving  1  percent  of  their 
time  represents  $36,600  per  year  and  the  system  will  doubtless 
save  more  than  that.  When  adding  to  that  the  money  expended 
by  the  NARF  on  materials -- being  almost  $60  million  in  1978 
[22] --it  becomes  obviously  clear  that  the  annual  benefits  will 
exceed  the  $122,100. 

Another  aspect  that  is  worthy  of  consideration  is  that 
the  MRP  system  may  also  be  implemented  at  other  industrial 
activities  in  the  future  so  that  the  initial  investment  in 
this  system  can  be  expected  to  reduce  the  investment  in  those 
future  systems. 

I.  IMPLEMENTATION  PLAN 

Implementation  of  the  proposed  system  should  consist  of 
the  following  phases :- 

1.  Establishing  a  development  team. 

2.  Software  design,  programming  and  documentation. 

3.  Conversion  of  the  data  base. 

4.  Testing. 

5.  Training  and  parallel  operation. 

6.  Post  implementation  reviews  and  improvements. 

The  development  team  should  consist  of  systems  analysts, 
programmers  and  user  representatives  and  should  be  responsible 
for  preparing  a  detailed  implementation  plan,  detailed  system 
design  and  implementation  of  the  system.  This  thesis  would 
provide  the  team  with  design  guidelines. 
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The  various  activities  that  take  place  in  each  phase  are 
described  in  detail  in  Appendix  C.  Figure  32  gives  anticipated 
project  schedules  for  implementation  of  the  system  as  well  as 
the  system  development  activities  and  human  resources  that  are 
needed  in  each  phase. 

When  going  into  actual  implementation,  it  will  be  very 
important  to  keep  in  mind  Woolsey's  [24]  "Ten  ways  to  go  down 
with  MRP."  Among  others  that  he  mentions,  the  following  should 
be  regarded  carefully  here: 

1.  "Only  involve  the  highest  level  of  management  in  defining 
the  'hands-on'  side  of  the  system." 

2.  "Don't  run  the  system  in  parallel,  just  shut  down  the 
manual  system  and  turn  on  MRP." 

3.  "Don’t  clean  up  your  bills  of  materials,  you  know  they 
are  right." 

4.  "Don't  require  sales  to  take  responsibility  for  screwing 
up  the  master  production  schedule." 

5.  "Install  the  system  as  a  surprise  to  Production  and 
Sales." 
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Running  temporary 
MRP  and  approval 
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Figure  32:  System  Development  and  Implementation  Activities 


VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  MRP  technique  is  designed  to  use  the  fact  that  the 
material  requirements  in  a  production  or  maintenance  oriented 
environment  are  driven  by  the  production  schedule.  However, 
the  technique  will  only  work  if  an  accurate  BOM  and  production 
schedule  exist. 

The  system  that  is  proposed  in  this  thesis  is  designed  to 
provide  the  means  for  developing  and  maintaining  an  accurate 
data  base.  Additionally,  it  provides  a  model  that  will  use 
that  data  effectively  to  generate  a  realistic  materials  fore¬ 
cast. 
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Planning  Horizon 


The  proposed  system  was  designed  to  meet  the  constraints 
imposed  by  the  current  budgetary  process  and  the  quarterly 
preparation  of  the  production  schedule.  This  implies  that  the 
system  does  not  have  the  capability  to  forecast  long  run  re¬ 
quirements,  nor  can  it  provide  all  requirements,  a  procurement 
lead-time  ahead  to  assure  that  all  materials  are  purchased  so 
that  all  scheduled  jobs  can  be  accomplishable.  This  situation 
can  obviously  be  improved  significantly  by  developing  long  run 
production  schedules  and  trying  to  stick  to  them  as  much  as 
possible.  This  appears  feasible  for  at  least  the  engine  and 
components  programs  that  represent  a  major  part  of  the  work¬ 
load  schedule  [ 21 ] . 

3 .  Frequency  of  Requirements  Generation 

Setting  of  the  RSS  stock  levels  is  currently  limited 
to  once  per  quarter.  This  corresponds  to  the  current  frequency 
of  determining  the  production  schedule.  It  may  be  eventually 
useful,  however,  to  regenerate  the  material  requirements  and 
reset  levels  on  a  monthly  basis,  thereby  decreasing  the  influ¬ 
ence  of  the  random  part  of  the  forecast.  However,  the  system 
should  be  used  at  least  for  one  year  with  the  present  frequency 
to  determine  its  performance  before  any  changes  are  made. 

4 .  Coordination  with  the  UICP 

The  MRP  forecast  cannot  be  effective  if  the  UICP 
system  does  not  assure  the  existence  of  the  required  materials 
within  the  wholesale  system.  Since  the  problem  is  related  to 
all  NARF's  and  not  just  to  Alameda  it  would  be  useful  to 
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coordinate  the  operation  of  both  systems  so  that  the  I’ICP 
could  use  the  long-run  forecasts  from  the  MRP  system  as  planned 
program  requirements. 

5.  ASKARS  and  NISTARS 

Although  these  two  systems  are  being  developed  inde¬ 
pendently,  there  will  undoubtedly  be  a  need  for  communication 
between  the  systems.  NISTARS  will  provide  the  storage  space 
for  the  RSS  and  will  also  maintain  a  data-base  which  contains 
vital  information  for  the  NARF ' s  day-to-day  operations  (for 
example,  inventories  on  hand).  Therefore,  setting  up  an 
appropriate  interface  between  the  systems  to  allow  direct 
access  of  one  system  to  the  other's  data-base  can  simplify 
file  maintenance  in  general  and  service  to  the  users  in 
particular . 

6.  FIC's  and  IIC's 

The  practice  of  preparing  the  production  schedule  by 
FIC  introduces  uncertainty  into  the  process  of  planning  material 
requirements  and  complicates  the  maintenance  of  the  MRP  system. 
Transition  to  planning  by  I I C  will  make  the  whole  process  much 
more  accurate  and  efficient. 

A  rather  different  subject  is  the  relationship  between 
ASKARS  and  MRP.  It  so  happened  that  the  ASKARS  system  will 
become  operational  at  the  right  time  for  implementation  of  the 
proposed  MRP  system.  However,  the  interaction  of  two  new 
systems  may  be  very  disastrous  and  therefore  it  is  recommended 
that  the  actual  implementation  of  the  MRP  system  be  delayed 
until  most  of  ASKARS’  "birth  problems"  have  been  resolved. 
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This  delay  time  should  be  utilized  to  get  better  acquainted 
with  the  MRP  system  through  the  experience  with  the  temporary 
system  and  to  purify  the  data-base.  This  period  should  also 
be  used  for  further  analysis  of  the  parameters  needed  for  the 
proposed  model. 

Another  area  that  is  related  to  the  MRP  system  and 
requires  further  analysis  is  the  policy  of  overhauling  complex 
end-items,  especially  aircraft.  The  current  policy  is  that 
whenever  an  end-item  is  overhauled  its  repairable  components 
are  also  overhauled  and  placed  back  on  the  same  aircraft. 

This  delays  the  completion  of  the  job  and  calls  for  inductions 
of  components  separately  from  the  regular  induction  of  such 
components  being  repaired  and  placed  in  the  supply  system. 

The  MRP  system  would  operate  best  if  repaired  components 
from  stock  were  used  in  the  aircraft  overhaul  and  components 
from  the  aircraft  that  needed  rework  were  returned  to  the 
supply  system  as  non- ready- for- issue  inventory.  The  advan¬ 
tage  of  this  policy  with  respect  to  MRP  is  that  it  provides 
more  accurate  values  for  the  replacement  factors.  As  men¬ 
tioned  earlier,  it  is  desired  to  make  the  decision  about  this 
subject  before  conversion  to  the  proposed  system  to  save  later 
changes  in  the  BOM  data. 

As  to  application  of  the  project  system  to  other  activities, 
it  appears  that  the  model  may  be  appropriate  for  other  indus¬ 
trial  activities  to  use.  However,  any  action  in  that  direction 
should  probably  not  take  place  before  the  model  proves  its 
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effectiveness  at  NARF  Alameda.  Much  will  undoubtedly  be 
learned  which  would  serve  to  save  time  and  effort  for  other 
applications . 


APPENDIX  A 


LIST  OF  SELECTED  UADPS-SP  PILES  [18] 

1.  Master  Stock  Item  Record  (MSIR) .  This  is  the  master 
inventory  status  file. 

2.  Planned  Requirement/Reservation  File  (PR/RFS) . 

3.  Receipt/Due  File  (R/D) . 

4.  Requisition  Status  File  (RSF) . 

5.  Demand  History  File  (DHF).  Together  with  the  RSF, 
represents  the  demand  history. 

6.  Address  Master  File  (AMF) . 

7.  Job  Order  File  (JOF) . 

8.  Master  Employee  Record  (MER) . 

9.  Receipt  History  File  (RHF). 

10.  Transaction/Reconstruction  File  (TRANSRECON) . 

11.  Demand  Master  File  (DMF) . 
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APPENDIX  B 


SUPPORTING  DATA-3 


1 .  Supporting  Data 

The  information  to  follow  is  required  for  estimating  the 
size  of  files,  processing  times,  and  the  required  storage 
resources  for  the  proposed  system.  The  estimates  are  based 
on  analyses  of  the  present  inventory  system  at  NSCO  and  the 
temporary  MRP  application. 

General  Data 

Approximate  number  of  active  FIC's  =  10,000 

Approximate  number  of  active  IIC's  =  14,000 

Maximum  number  of  IIC’s  per  FIC  =  50 

Average  number  of  consumable  NSN's  per  IIC  =  50 

Maximum  number  of  consumable  NSN's  per  IIC  =  1,200 

Average  number  of  shops  participating  in  IIC  overhaul  =  12 

Maximum  number  of  shops  per  IIC  (all  that  exist)  =  150 

Number  of  active  NSN's  (used  by  the  NARF)  *  35,000 

Number  of  active  job  orders  =  28,000 

Number  of  material  planners  =  120 

2 .  Transactions  Volumes  and  Processing  Frequencies 

Table  B-l  describes  the  different  software  modules,  and  the 
type  and  volume  of  transactions  processed  by  each  module. 

^Obtained  from  personal  interviews  with  LCDR  W.P.  Benefiel, 
500  Department,  NARF  Alameda,  February  1980. 
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TABLE  B-l 


Transactions,  Volumes  and  Processing  Frequencies 
for  the  Proposed  MRP  System 


Software  Module 

Name  of 

Trans act  ion/ Prog ram 

Number  of 

T  r ansae  t ions /Runs 

File  maintenance 

BOM 

Induction  data 

Requis it  ions 

Estimation  transac¬ 
tions 

BOM  update  run 

150,000  per  year* 
200,000  per  year* 
10,000  per  quarter 

Once  per  quarter 

FIC  to  IIC 

Translation  Table 

QFT  transactions 

Induction  data 

Table  update 

40,000  per  quarter 
150,000  per  year 

Once  per  quarter 

PCS 

Status  transactions 

Expended  hours 
transactions 

File  maintenance  run 

Production  schedule 
listing 

Exception  report 
Queries 

5(1,000  per  quarter 

1,000,000  per  qtr 

Weekly  run 

Monthly 

Monthly 

3,000  per  quarter 

Queries 

Inquire  BOM  by  IIC 
Inquire  BOM  by  FIC 
Inquire  MRP  forecast 
Modify  MRP  forecast 

8,000  per  quarter 
2,000  per  quarter 
2,500  per  quarter 

500  per  quarter 

Requirements 

generation 

Expended  materials 
transactions 

"Raw"  material 
requirements 

RSS  level  setting 
transactions 

30,000  per  quarter 

75,000  per  quarter 

20,000  per  quarter 

*The  figures  are  inflated  to  represent  overload  during  war  time 
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APPENDIX  C 


SOFTWARE  DEVELOPMENT 

1 .  Software  Development  Activities 

The  development  of  the  MRP  software  will  involve  the 
following  activities:- 

a.  Design  and  Programming 

Detailed  specif ications  have  to  be  written  for  each 
software  module,  file  and  processing  run.  These  specifica¬ 
tions  will  then  be  translated  into  computer  programs  which 
will  be  later  tested  to  assure  their  compliance  with  the 
design. 

b.  Conversion 

This  phase  involves  preparations  and  actual  conver¬ 
sion  from  the  temporary  MRP  system  to  the  proposed  applica¬ 
tion.  To  do  this,  special  programs  will  have  to  be  written 
to  convert  the  old  data  base  to  the  new  structure  and  to 
insert  default  values  in  those  fields  that  did  not  exist 
before . 

Because  of  the  nature  of  the  application  it  is  possible 
and  very  desirable  to  operate  both  systems  in  parallel  for 
one  quarter.  However,  when  the  final  system  is  accepted  it 
would  be  appropriate  to  have  a  short  (say,  two  days')  break 
in  running  the  application.  This  period  would  allow  all  the 
transactions  in  the  old  system  to  be  processed  and  the  "live" 
conversion  to  take  place. 
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c.  Testing 

This  phase  includes  testing  of  individual  software 
modules,  programs  and  processing  runs.  Different  transaction 
paths  and  options  of  the  system  should  be  tested  to  make  sure 
that  it  all  works  as  expected. 

The  end  of  this  phase  involves  a  user's  acceptance 
test  during  which  the  user  tests  the  system,  and  then  accepts 
responsibility  for  normal  operations  if  the  test  is  success¬ 
fully  passed. 

d.  Parallel  Operations 

While  the  old  system  is  still  running,  the  new  one 
should  run  in  parallel.  This  will  allow  the  new  system  to 
be  checked  out  before  the  old  system  is  shut  down.  This 
phase  also  allows  the  users,  and  especially  the  material 
planners,  to  get  acquainted  with  the  new  system,  learn  how 
to  inquire  and  how  to  use  the  system's  output. 

e.  Documentation 

Documentation  of  the  system  should  be  done  during 
the  entire  course  of  the  project.  At  the  early  phases,  the 
emphasis  should  be  on  documenting  decisions  and  reasons  for 
selecting  specific  options  or  procedures.  In  the  later 
stages  the  emphasis  should  be  on  documentation  of  the  soft¬ 
ware,  data-base,  input,  output,  and  use  of  the  system. 

The  documentation  should  cover  all  modules,  the 
interfaces  between  the  modules  and  interrelation  between  the 
modules.  Operational  manuals  should  be  provided  describing 


regular  operations  and  actions  to  be  taken  when  irregular 
events  ("bugs")  occur. 

f.  Training 

Involvement  of  the  users  in  the  early  design  stages 
will  pay  off  when  time  for  training  comes.  However,  training 
should  be  provided  to  all  users  and  people  that  are  involved 
in  running  the  system  (operators,  I/O  clerks)  to  assure  that 
they  know  how  to  handle  the  inputs  and  how  to  use  the  outputs 
and  the  services  the  system  provides. 

g.  Post  Implementation  Reviews 

After  the  system  goes  into  normal  operation,  it  would 
be  very  desirable  to  have  at  least  one  or  two  post  implemen¬ 
tation  reviews.  These  are  meetings  of  the  development  team 
and  the  users  in  which  problems  are  brought  up  and  discussed. 
If  there  are  problems,  the  group  should  identify  its  source 
and  find  a  solution  that  will  satisfy  the  users.  However,  it 
is  advantageous  to  collect  requests  for  small  changes  rather 
than  implementing  each  one  as  it  comes  up.  In  addition,  these 
changes  should  be  examined  to  see  if  they  are  really  needed. 

2 .  Development  Times 

The  cost  of  the  software  development  will  be  based  on  the 
size  and  complexity  of  the  different  modules  (25].  The 
following  productivity  standards  will  be  assumed  in  this 
process : - 

1.  Programming  --  Fifty  source,  high- level - language  state¬ 
ments  per  programmer  per  week  (for  simple  level  1 
complexity  programs).  A  statement  in  a  simple  program 
will  be  the  "standard  unit." 
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2.  Testing  --  150  statements  of  complexity  1  per  programmer 
per  week. 

3.  Documentation  --  15  percent  of  total  programming  and 
testing  time. 

4.  File  Conversion  --  approximately  the  same  as  file 
maintenance. 

5.  Training  and  Parallel  Operation  --  two  training  days 
for  each  user/operator. 

Table  C-l  shows  the  derivation  of  the  total  size  of  the 
software  (in  "standard"  statements)  and  allows  derivation  of 
the  software  development  times  as  follows: - 

1.  Programming  time  =  8650/50  =  173  man-weeks-  44  man-months. 

2.  Testing  time  =  8650/150=  58  man-weeks  =  14  man-months 
(8  programmer  man-months  and  4  analyst  man-months). 

3.  Documentation  time  -  (44  +  11)  x  .15  =  8  man-months. 

4.  File  conversion  time  =  (2250  +  300  +  1500)/50  =  81  man- 
weeks  -  20  man-months  (15  programmer  man-months  and 

5  analyst  man-months). 

5.  Training  and  parallel  operations  time  involves: 

a.  0.5  programmer  man-months. 

b.  0.2  analyst  man-months. 

c.  0.2  operators  man-months. 

d.  1.0  clerk  man-months. 

In  addition  to  that,  analyst  time  is  required  for  prepar¬ 
ing  the  detailed  specifications  for  the  MRP  application. 

Based  on  the  time  that  this  study  took,  it  is  estimated  that 
3  more  man-months  of  analyst  time  are  required. 

Adding  together  all  elements  gives  the  following  times :- 

1.  75.5  programmer  man-months. 

2.  14.2  analyst  man-months. 
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TABLE  C-l 


Software  Size 


Module 

Program 

Source 

Statements 

Complexity 

Standard 

Units 

File 

Maintenance 

BOM- -Input  edit 

Extract 

2S0 

50 

1 

250 

50 

1 

Update 

750 

3 

2  250 

FIC  to  IIC  trans¬ 
lation  table 

Extract 

50 

1 

50 

Update 

150 

2 

300 

PCS--Input  edit 

250 

1 

250 

Update 

500 

3 

1500 

Queries 

Query  "Driver" 

100 

2 

200 

Query  BOM 

100 

2 

200 

Query  MRP 
forecast 

300 

2 

600 

Modify  MRP 
forecast 

500 

3 

1500 

Requirements 

Extract  inputs 

50 

1 

50 

Generation 

Generate  forecast 

250 

2 

500 

Reformat  output 

50 

1 

50 

Generate 

transactions 

100 

1 

100 

Subroutines 

MRP  subroutine 

150 

2 

300 

functions 
and  report 
generators 

Read/write 

functions 

200 

2 

400 

IIC  from  job 
order 

100 

1 

100 

Total 

3900 

8650 

_ 
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3.  0.2  operator  man-months. 

4.  1.0  clerk  man-months. 

5.  8.0  material  planners  man-months  (based  on  120  planners). 

These  figures  imply  that  the  implementation  of  the  system 
in  a  period  of  one  year  requires  the  employment  of  six  pro¬ 
grammers  and  one  systems  analyst.  However,  because  the  load 
is  not  equally  distributed  during  the  year  it  may  well  happen 
that  at  some  times  additional  programmers  (or  overtime)  and/or 
systems  analysts  will  be  needed. 
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APPENDIX  D 


UPDATING  REPLACEMENT  FACTORS 

The  replacement  factor  represents  the  proportion  of  a 
consumable  item  that  is  expected  to  be  replaced  when  the  end- 
item  that  includes  that  consumable  is  being  replaced.  The 
replacement  factor  is  expected  to  change  during  the  useful 
life  of  an  end-item  because  of  ; 

1.  Aging  of  the  item; 

2.  Changes  in  maintenance  policies; 

3.  Estimated  replacement  factors  found  to  be  in  error. 

Consequently,  there  are  two  ways  to  update  the  replacement 

factor. 

1 .  By  Transaction 

The  transactions  that  are  submitted  by  the  material 
planners  (see  BOM  file  maintenance)  will  set  the  "estimated 
replacement  factor"  field  in  the  BOM  file  to  the  value  reported 
in  the  transaction  and  will  update  the  "estimator  code"  and 
"date  of  last  estimate"  as  well. 

2 .  By  Actual  Replacement  Information 

During  the  BOM  file  maintenance  run,  actual  replace¬ 
ment  factors  are  computed.  The  actual  replacement  factor  is 
the  ratio  between  the  total  quantity  of  the  item  replaced  in 
overhaul  of  a  certain  IIC  and  the  total  installed  quantity 
of  that  consumable  in  the  whole  quantity  that  was  inducted. 
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This  new  replacement  factor  will  be  used  to  update  the 
"actual  replacement  factor." 

Various  methods  exist  for  updating  information  such 
as  the  replacement  factors.  The  most  simple  would  be  to  com¬ 
pute  a  weighted  average  of  the  new  and  the  old  replacement 
factors  where  the  weights  are  proportional  to  induction 
quantities.  A  variation  on  that  would  be  a  simple  moving 
average  [29].  This  method  is  utilized  in  the  temporary  MRP 
system.  The  Exponential  Smoothing  method  is  still  another 
method  often  used  in  such  cases.  Its  big  advantage  is  that 
it  needs  no  other  data  but  the  old  and  new  factors  and  the 
smoothing  constant. 

Forecasting  usually  involves  a  start-up  problem. 

The  information  that  is  initially  available  is  an  estimate 
and  the  problem  is  how  to  phase  it  out  and  replace  it  by 
actual  data  as  it  becomes  available.  The  intent  of  the  pro¬ 
posed  procedure  for  updating  the  replacement  factors  is  to 
utilize  information  of  both  actual  and  estimated  factors  and 
to  gradually  phase  in  actual  data  so  that  as  soon  as  suffi¬ 
cient  actual  experience  is  available  the  estimate  will  be 
ignored.  To  do  that,  two  separate  fields  are  maintained  in 
each  "consumable"  trailer  in  the  BOM  file,  one  for  the  esti¬ 
mated  replacement  factor  and  the  other  for  the  actual  factor. 
An  additional  field  is  used  as  a  counter  of  the  total  induc¬ 
tion  quantity  on  which  the  actual  replacement  factor  is  based. 
The  contents  of  the  estimate  field  are  derived  from 
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transactions,  each  new  estimate  for  an  I IC/consumable  over¬ 
riding  the  previous  one.  The  actual  replacement  factor  is 
set  to  zero  when  the  trailer  is  created  and  also  whenever  a 
new  estimate  is  processed.  At  the  first  time  an  actual 
factor  is  computed,  it  will  override  the  zero.  In  subsequent 
updates,  a  new  actual  replacement  factor  will  be  computed 
using  exponential  smoothing  as  follows: 


F 

rN  +  l 


0.9  Fv  +  0.1  F, 
N  A 


where , 

Fn+1  is  the  new  "actual”  replacement  factor, 

Fjj  is  the  old  "actual"  replacement  factor,  and 

F^  is  the  actual  replacement  factor  computed 
from  last  quarter's  data. 


The  determination  of  the  replacement  factor  to  be 
used  by  a  program  will  be  done  by  a  subroutine.  This  sub- 
roc  tine  will  return  to  the  calling  program  the  replacement 
factor  which  results  from  the  information  in  the  fields  con¬ 
taining  the  estimated  factor,  the  actual  factor,  the  date  of 
estimation  and  the  total  induction  quantity.  The  algorithm 
for  determining  the  replacement  factor  is  as  follows: 

1.  If  no  actual  factor  exists,  return  the  estimate. 

2.  If  an  actual  factor  exists  and  the  date  of  the  estimate 

is  more  than  a  year  old,  return  the  actual  factor. 

3.  If  the  above  conditions  are  not  satisfied,  compute  the 

factor  to  be  returned  by  exponentially  smoothing  the 
estimated  and  the  actual  replacement  factors.  The 
coefficient,  a,  to  be  used  will  be  determined  according 
to  the  total  induction  quantity.  For  example: 
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a.  If  the  induction  quantity  is  less  than  10,  a  =  0.1; 


b.  If  the  induction  quantity  is  in  the  interval 
[10,  100]  ,  a  =  0.5; 

c.  If  the  induction  quantity  is  greater  than  100,  a  =  1.0. 


The  various  parameters  mentioned  above,  namely,  the 
period  before  the  estimate  is  totally  phased  out,  and  the 
intervals  of  total  induction  quantity  for  the  variance  a 
values,  may  have  to  be  "tuned-up”  after  some  experience  is 
gained . 
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If  the  budget  constraint  is  not  satisfied,  the  technique 
of  Lagrange  can  be  used  to  get  a  modified  form  of  equation 
(5);  namely. 


C  +  C,  +  [k  +  0  ]  C 

F(y)  -  -E - * - 

TT^  +  kC 


(9) 


The  approach  is  then  to  introduce  trial  values  of  0,  deter¬ 
mine  the  resulting  set  of  y  values  using  equation  (9) ,  compute 
the  associated  sum 


m 

£  C  y  , 

i  =  l  1  1 

and  compare  it  with  B.  If  the  sum  is  less  than  B  the  value 
of  0  should  be  reduced;  if  the  sum  is  still  greater  than  B 
the  value  of  0  should  be  increased.  The  search  terminates 
when  a  value  of  0  results  in  the  sum  being  equal  to  B.  The 
associated  y^  values  are  the  budget  constrained  optimal 
quantities  of  the  m  repair  parts  to  place  in  the  RSS. 

Is  a  Budget  Constraint  Appropriate? 

The  model  developed  above  assumes  a  static  situation  in 
which  the  production  schedule  and  the  budget  constraint  are 
given.  However,  imposing  both  constraints  in  advance  may 
have  an  adverse  effect  on  the  ability  of  the  NARF  to  meet 
that  schedule.  It  may  well  happen  for  a  given  component 
undergoing  repair,  that  the  items  with  100%  replacement  will 
be  available  in  stock  whereas  other  items  (for  which  P  <  1) 
would  not  be  there.  Consequently,  what  may  happen  is  that 
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instead  of  having  complete  kits  of  parts  required  to  complete 
a  job  there  will  be  only  "partial"  kits,  i.e.,  all  the  parts 
replaced  1 Q 0 %  of  the  time  and  some  of  those  where  p  <  1.0  . 

In  such  a  case  there  is  no  way  in  which  a  job  could  be  com¬ 
pleted.  Moreover,  those  parts  that  are  in  stock  may  remain 
useless  because  of  the  shortage  in  other  parts. 

The  conclusion  is  that  the  proper  way  to  go  is  to  schedule 
jobs  into  the  NARF  so  that  the  budget  will  be  sufficient  to 
provide  all  materials  predicted  by  the  model  thereby,  in  fact, 
assuring  that  the  constraint  is  not  active.  However,  it  might 
be  logical  to  prepare  a  reserve  of  job  orders  for  the  case 
that  actual  consumption  was  lower  than  the  forecast.  The 
proper  way  to  provide  protection  against  such  an  event  is  to 
induct  additional  quantities  of  the  items  that  have  been 
inducted  previously. 

Reducing  the  Number  of  Scheduled  Jobs 
because  of  a  Budget  Constraint 

To  avoid  the  problems  described  above,  it  would  be 
natural  to  schedule  jobs  so  that  their  material  requirement 
would  not  exceed  the  budget  vice  changing  the  quantities  of 
the  materials  placed  in  stock.  To  meet  that  goal,  the  orig¬ 
inal  list  of  job  orders  should  be  split  into  groups  of  jobs, 
each  group  containing  jobs  of  some  priority.  Then,  the 
algorithm  should  be  applied  to  each  set  of  jobs  to  determine 
the  budget  it  requires.  When  this  step  is  completed,  one 
can  determine  which  jobs  can  be  scheduled  so  that  their 
material  requirements  would  not  exceed  the  budget,  or  on 
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the  other  hand,  determine  what  increase  in  budget  will  allow 
the  scheduling  of  some  additional  jobs. 

The  Back-up  Stock  (w)  from  the  Wholesale  Supply  System 

w  is  a  variable  quantity.  Although  the  quantity  of  back¬ 
up  stock  is  known  at  the  start  of  the  quarter  or  when  planning 
occurs,  the  amount  available  at  the  time  it  is  needed  depends 
among  others,  on  the  demand  the  item  experienced  from  other 
activities  during  the  time  from  the  start  of  the  quarter  until 
the  time  when  the  shortage  occurred.  It  may  be  appropriate 
to  use  as  w  the  amount  of  the  item  prepositioned  as  war 
reserves.  However,  this  assumption  requires  having  a  per¬ 
mission  to  actually  use  that  stock  in  the  event  that  a  short¬ 
age  occurs  in  the  RSS  stock  and  the  quantity  in  the  regular 
wholesale  supply  is  insufficient. 

Perhaps  a  sensitivity  analysis  will  provide  guidance  as 
to  the  appropriate  assumptions  to  make  about  the  value  of  w. 

Which  Constants  to  Use 

The  model  requires  the  following  constants: 

Cp  -  Processing  costs 
-  Holding  costs 

it,  -  Shortage  cost  for  item  obtained  from  local 
wholesale  supply 

7T 2  -  Shortage  costs  for  items  obtained  somewhere  else 
k  -  Surplus  cost  factor 

It  is  logical  to  assume  that  these  constants  have  specific 
values  for  each  item  used  in  repair  of  a  component.  It  is 
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relatively  simple  to  determine  the  values  of  Cp  and  and 
it  may  as  well  be  logical  to  apply  these  constants  to  groups 
of  items  of  similar  nature.  This  is  not  the  case,  however, 
with  it ^ ,  7t 2 ,  and  k.  The  shortage  cost  depends  not  only  on 
the  item  that  is  not  available  but  also  on  the  specific 
circumstances  of  a  given  job  that  requires  the  part  and  on 
the  circumstances  of  other  jobs.  That  is  also  true  for  k. 
Consequently,  tt  ^ and  k  may  vary  from  job  to  job,  from 
part  to  part,  and  even  from  time  to  time  for  the  same  job/ 
part.  It  may  be  useful  to  note  that  k  can  be  viewed  as  the 
"knob"  that  adjusts  the  surplus  cost  [see  equation  (9)]  in 
much  the  same  way  as  is  done  in  the  UICP  model  where  the 
"knob"  is  the  shortage  cost.  Also,  when  a  budget  constraint 
is  imposed,  it  may  be  viewed  as  increasing  the  value  of  the 
surplus  cost  resulting  from  k,  causing  a  solution  for  y  more 
in  favor  of  a  shortage. 

Pragmatic  Aspect 

Maintaining  the  different  constants  for  each  item  and, 
in  particular,  having  it  done  by  the  NARF,  would  be  prohib¬ 
itively  complicated.  The  system  may  become  significantly 
more  simple  if  the  constants  could  be  determined  for  groups 
of  items  rather  than  for  each  item.  It  seems  logical  to  begin 
by  establishing  values  spanning  groups  of  items  (and  keeping 
those  constants  in  a  table  that  will  be  shared  by  different 
application  programs). 
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